Perfecto. Con el esquema “Ferduino Mega 2560” que adjuntaste (esquema general en una sola hoja con bloques: Ethernet, TFT, RF, RTC, temperatura, relés, dosificadoras, nivel, etc., y tabla de asignación de pines del Mega) yo lo enfocaría como shield para Arduino Mega 2560 priorizando fabricación simple y BOM < 200 USD.

A continuación te dejo un diseño “industrializable” y realista.

1) Estrategia clave para bajar coste y simplificar fabricación

A. La shield NO debe “repetir” el Arduino

El PDF integra el “Arduino circuit” (ATmega2560, ATmega16U2, USB, etc.). Para una shield, todo eso se elimina: el Mega ya lo aporta.
En la shield solo quedan periféricos + drivers + conectores, usando los pines que el esquema lista (muy importante para compatibilidad).

B. Modulariza lo “caro/difícil” con footprints de módulos (opción recomendada)

En vez de soldar QFP/QFN finos (Ethernet W5100, RF, etc.), diseña la PCB para montar módulos estándar:

• Ethernet: módulo W5500/W5100 por SPI (módulo típico con header 2.54 mm)

• RTC: módulo DS3231 (más estable que DS1307 y suele costar parecido)

• RF: módulo RFM12B/RFM69/RFM95 según tu firmware (deja footprint y pines compatibles)

• TFT/Touch: conector para un módulo TFT SPI (o FFC si de verdad necesitas paralelo)

Esto reduce:

• coste de ensamblaje,

• riesgo de fabricación,

• necesidad de 4 capas,

• retrabajos.

2) Arquitectura de la shield (bloques)

Basado en los bloques del esquema :

2.1 Alimentación y protección (prioridad #1)

Entrada típica 12 V (en el esquema aparece 12V) . Para shield:

• Jack DC o bornera (mejor bornera 5.08 mm).

• Protección: fusible rearmable (PTC) + TVS 600 W + diodo contra polaridad (ideal MOSFET “ideal diode”, pero un Schottky grande también vale si el consumo no es enorme).

• Buck 12V→5V (recomendado) en vez de linear: un step-down tipo MP1584/MP2307 (o módulo).

• 3.3 V desde 5 V: LDO AMS1117-3.3 o mejor uno más eficiente/menos caliente si RF+Ethernet consumen.

Regla práctica: si vas a manejar relés/bombas/LEDs desde 12V, separa bien “Power GND” y “Logic GND” y únelos en estrella cerca de la entrada.

2.2 Comunicaciones: SPI/I2C como “backbone”

• SPI para Ethernet + SD + (idealmente) TFT si eliges TFT SPI.

• I2C para RTC y expansor IO (PCF8575 aparece en el esquema).

El propio esquema marca usos como “SPI”, “SDA/SCL RTC”, “SDA/SCL PCF8575”, “SS Ethernet”, etc.

2.3 Relés / salidas de potencia

En el esquema se usan drivers tipo ULN2803/ULN2003 para cargas.
Para una shield fabricable:

• Relés: usa ULN2803A para bobinas 5 V (con diodos integrados) + relés Songle SRD-05VDC-SL-C o equivalentes.

• Si el sistema conmuta 230 VAC: añade distancias/ranuras (slots) y optoacoplo si quieres robustez.

• Para PWM (coolers, wavemaker, LED): MOSFET N canal logic-level (AO3400/IRLZ44N según corriente) + diodo flyback si es motor DC.

2.4 Bombas dosificadoras (stepper/peristálticas)

En el esquema aparece “DOSING PUMPS CIRCUIT” y ULN2003.
Interpretación típica: bombas DC o steppers pequeños.

• Si son steppers 28BYJ-48: ULN2003 perfecto (barato).

• Si son DC: MOSFET + PWM (y filtrado EMC).

2.5 Sensores: nivel + temperatura

• Nivel: entradas digitales con pull-up y protección ESD.

• Temperatura: DS18B20 (en el esquema hay conectores “1-DS18B20 / 2-DS18B20 / 3-DS18B20”).

  • Pon 4.7 k pull-up en el bus 1-Wire, protección ESD y conector 3 pines (GND/DQ/VCC).

2.6 RF

El esquema indica RFM12B 433 MHz y “SS RFM12” en A15.
Para shield:

• Deja footprint de módulo RFMxx con header y pad de antena.

• Plano de masa y keep-out alrededor de la antena.

• Alimentación 3.3 V bien desacoplada (100 n + 10 µF cerca).

3) Asignación de pines: respétala para compatibilidad

La hoja trae una tabla explícita de “ARDUINO PINS” con funciones (alarm, relays, wavemaker, RTC, PCF8575, etc.). Para que tu shield sea drop-in compatible con ese firmware/idea, clona esa asignación tal cual.

Mi recomendación práctica:

• En el esquemático de tu shield crea un bloque “MEGA2560 HEADER MAP” donde cada señal tenga:

  • Pin físico del header,

  • señal (ej. SDA/SCL/SPI/SS),

  • etiqueta funcional (RTC, Ethernet, etc.).

Así reduces errores al rutear.

4) Diseño PCB “barato y fácil de fabricar”

Reglas de fabricación (para 2 capas económico)

• 2 capas FR4 1.6 mm, cobre 1 oz.

• Pistas mínimas: 6/6 mil (mejor 8/8 mil si quieres cualquier fabricante).

• Vías estándar 0.3/0.6 mm.

• Componentes SMD grandes: 0603/0805; conectores THT.

• Stacking headers de Arduino Mega (para shield).

• Borneras 5.08 mm para potencia/salidas.

• Separación alta tensión si aplica.

Layout recomendado (por bloques)

• Zona “dirty power” (12 V, relés, MOSFETs) en un borde.

• Zona lógica (I2C/SPI/MCU headers) al centro.

• Zona RF en esquina con keep-out.

• Ethernet cerca del RJ45 si usas MagJack o módulo con RJ45.

5) Dos enfoques concretos (elige según fidelidad vs simplicidad)

Opción 1 — “Compatible y fabricable” (mi preferida)

Mantienes funciones del esquema, pero usando módulos donde convenga:

• Ethernet por módulo W5500 (SPI).

• RTC por módulo DS3231 (I2C).

• RF por módulo RFM.

• TFT SPI (en vez de bus paralelo de muchos pines) si tu firmware lo permite.

Ventajas: 2 capas viable, menos soldadura fina, BOM más barata, ensamblaje manual posible.

Opción 2 — “Clon más literal”

Replicas más fielmente los ICs (W5100, buffers 74HC, etc. como se ve en el esquema).
Contras: sube complejidad, casi seguro 4 capas o routing muy denso, ensamblaje SMD fino, más riesgo (y coste).

6) Presupuesto objetivo < 200 USD (estimación realista)

Sin saber cantidades (1 unidad vs lote), para 1 unidad:

• PCB 2 capas (10×10–15×15 cm aprox): 15–40 USD

• Conectores (headers, borneras, RJ45 si aplica): 15–35 USD

• Drivers (ULN2803/2003, MOSFETs, diodos, pasivos): 10–25 USD

• Relés (8–16 canales según diseño): 10–35 USD

• Módulo Ethernet: 5–15 USD

• RTC DS3231: 2–6 USD

• RF: 5–15 USD

• Sensores/conectores DS18B20: 5–15 USD

Total típico: ~70 a 170 USD, dependiendo mucho de:

• número de relés/canales PWM,

• si incluyes TFT/Touch en el kit,

• si el RJ45 va integrado o por módulo,

• calidad de borneras y protección eléctrica.

En pequeño lote (10–50 uds) normalmente baja bastante.

7) Checklist para que “funcione a la primera”

1. Definir corrientes reales por salida (relés, bombas, LED) → dimensiona pistas, MOSFETs, conectores.

2. Separación masas y retorno de corriente (evitar resets por ruido).

3. ESD en conectores externos (temperatura, nivel, RF, puertos largos).

4. Si conmutas AC: creepage/clearance + ranuras + fusible serio.

5. Validar que SPI no tenga conflictos de SS (Ethernet, SD, RF).

6. Test-points en: 12V, 5V, 3V3, SDA, SCL, SCK, MOSI, MISO, RESET.

Si quieres, en el siguiente paso te lo aterrizo a un esquemático de shield por bloques (lista de componentes + conexiones) y un BOM optimizado a coste manteniendo la misma asignación de pines del PDF.

Perfecto: ese PDF de “posición de componentes” es oro para convertir el proyecto en shield porque te fija la mecánica, las zonas de potencia, y los conectores perimetrales (que es lo que más encarece/rediseña cuando no cuadra). En la página 1 se ve claramente el “board outline” con: 4 BNC en el borde superior, un DB25 arriba, un DB9 lateral, una zona de relés/driver ULN2803, el módulo Ethernet (W5100) con su RJ45, el zumbador, el porta-pila CR2032 con DS1307, y una fila inferior de conectores “SENSOR1..SENSOR6” + conectores DS18B20.

A partir de ese “placement” yo diseñaría la shield así:

1) Mantén la misma “topología” de bloques (reduce iteraciones)

Usaría el gráfico como plantilla de floorplan:

• Borde superior (señal/analógico): los 4 BNC alineados (BNC1..BNC4). Mantenerlos en borde y con masa alrededor ayuda a EMC y a que el cableado sea limpio.

• Superior derecha (interfaz externa): DB25 (y su keep-out) tal como está: ese conector manda la mecánica de la placa.

• Derecha (Ethernet): el bloque del W5100/RJ45 está dibujado pegado al borde derecho; eso es lo correcto por longitud de pares y para que el RJ45 asome. Si lo vas a simplificar, aquí es donde conviene poner un módulo W5500/W5100 para evitar el routing fino.

• Zona central-superior: drivers ULN2803 (aparecen “ULN2803/1” y “ULN2803/2”). Mantenerlos arriba reduce la longitud hacia relés/salidas y separa conmutación de la zona de sensores.

• Centro (RTC): CR2032 + DS1307 se ven centrados: buena posición, lejos de bordes, menos golpes y menos interferencia. Yo lo haría con DS3231 (si mantienes pinout I2C es transparente para la shield en muchos casos).

• Inferior (sensores/low-voltage): “SENSOR1…SENSOR6” en el borde inferior y los conectores de DS18B20 a la derecha. Esto es ideal: todo el cableado de sondas sale por abajo, y dejas potencia/relés “arriba”.

Resultado: menos ruido en sensores y menos rediseño mecánico.

2) Conviértelo en shield Mega: mecánica y headers

El dibujo que adjuntas parece la PCB “todo en uno” con el Mega integrado (se ve el ATmega grande y el USB). Para shield:

1. Elimina todo lo del micro/USB del diseño (ATmega, 16U2, cristal, USB, etc.).

2. Coloca los headers de Arduino Mega 2560 (los 4 headers estándar + el de power) respetando el “offset” típico del Mega.

3. Mantén el perímetro y conectores “de usuario” (BNC/DB25/RJ45/borneras) en posiciones similares al gráfico para que el cableado externo sea compatible.

El punto crítico: si quieres que sea “plug & play” con el firmware/pinout del esquema, debes respetar también la asignación de pines del Mega (como ya comentamos del PDF del esquema).

3) Ajustes de placement para fabricación barata (2 capas)

Basado en lo que se ve en la página 1 :

A. Separación “Potencia vs Señal”

• Arriba/derecha: Ethernet + drivers + relés/MOSFETs.

• Abajo: sensores, DS18B20, entradas de nivel.

• Une masas en un punto “estrella” cerca de la entrada de alimentación.

B. Rutas cortas para lo sensible

• Ethernet: si NO usas módulo, la parte de pares diferenciales y magnetics te complica 2 capas. Para coste/éxito, módulo con RJ45 es el camino.

• BNC: deja plano de masa alrededor, y evita que pistas de relés pasen por debajo.

C. Conectores en borde y “keep-outs”

Tu placement ya marca bien los “keep-outs” mecánicos del DB25/DB9/RJ45. Respétalos porque son fuente #1 de “la caja no cierra”.

4) Qué partes del original yo “modularizaría” sí o sí

Para salir por <200 USD y poder fabricar sin ensamblaje complejo:

• Ethernet: footprint para módulo W5500/W5100 (SPI).

• RTC: módulo DS3231 o IC + CR2032 como en el gráfico (pero DS3231 recomendable).

• RF: footprint de módulo (RFMxx).

• Relés/ULN2803: esto sí lo dejaría discreto en PCB (es barato y fácil).

Esto mantiene el aspecto y conectividad del placement, pero reduce muchísimo riesgo de fabricación.

5) Siguiente paso inmediato (sin pedirte más info)

Con estos dos PDFs ya puedo proponerte un “plano de shield”:

• lista de conectores por borde (arriba/abajo/izquierda/derecha)

• qué se queda en PCB vs qué va como módulo

• un BOM objetivo (por rangos) para asegurar <200 USD

• y reglas de PCB 2 capas (ancho de pistas de potencia, distancias, etc.)

Si quieres que lo deje todavía más “cerrado”, dime solo esto (una frase por punto, sin detalles):

1. ¿Conmutas 230 VAC con los relés o solo DC?

2. ¿Pantalla TFT sí/no? (y si es SPI o paralela)

Con eso lo aterrizo ya a una arquitectura final de shield sin sorpresas de coste.

Perfecto: ya revisé el proyecto del ZIP y aquí está el impacto real en el código si cambias el RTC.

Qué RTC usa el firmware ahora mismo

En el código del controlador se instancia un objeto RTC_DS rtc; y se incluye la librería rtc_ds (carpeta Bibliotecas/rtc_ds). Esa librería está escrita para DS1307.

En el firmware, el RTC se usa para:

• Leer hora/fecha: rtc.getTime()

• Mostrar strings: rtc.getTimeStr(), rtc.getDateStr(), rtc.getDOWStr(), rtc.getMonthStr()

• Validación de fechas: rtc.validateDate() / rtc.validateDateForMonth()

• Timestamp tipo “Unix-like”: rtc.getTimeStamp()

• Y, muy importante: el firmware llama a rtc.halt(true/false) alrededor de setTime() y setDate() (también lo hace en Setup.h con rtc.halt(false)).

No he visto que el firmware use RAM interna del DS1307 (readBuffer/writeBuffer, peek/poke) ni SQW, lo cual simplifica mucho la migración.

Si cambias DS1307 → DS3231: qué se rompe y qué no

Lo que NO suele romperse

DS3231 comparte el mismo I2C address (0x68) y el mapa de registros básicos de tiempo/fecha en 0x00–0x06 es compatible en la práctica, así que:

• getTime(), setTime(), setDate(), y los strings suelen seguir funcionando sin tocar nada.

Lo que SÍ es delicado (en tu firmware actual)

Tu librería rtc_ds implementa halt() escribiendo el bit CH (Clock Halt) en el registro de segundos (bit 7 de REG_SEC), que es correcto para DS1307.

En DS3231 no existe CH en el registro de segundos; el control del oscilador se hace con el bit EOSC en el registro de control 0x0E. Por eso, si dejas halt() tal cual:

• puede que “no pase nada” (muchos DS3231 ignoran ese bit),

• o puede introducir comportamientos raros si tu clon/variant no lo ignora como esperas.

Conclusión: si quieres DS3231, toca modificar halt() (o eliminar su uso en el firmware).

Dos caminos recomendados

Camino A (cero cambios de firmware): mantener DS1307

Si tu prioridad es “shield compatible” sin tocar software:

• Deja DS1307 + cristal 32.768 kHz + CR2032 como el original.

• Coste BOM mínimo, riesgo mínimo.

Contra: precisión peor (deriva típica mayor que DS3231).

Camino B (mejor RTC, cambios mínimos): usar DS3231 y parchear solo halt()

Es lo que yo haría si quieres un producto más “pro”.

Opción B1 — “halt() como NO-OP” (lo más simple)

Como tu código solo usa halt() para “congelar mientras setea”, en DS3231 puedes directamente no hacer nada en halt().

Ventaja: cero efectos secundarios.
Riesgo: prácticamente nulo.

Parche (conceptual):

• En DS1307.cpp (librería rtc_ds), cambiar RTC_DS::halt(bool enable) por:

  • { (void)enable; }

Opción B2 — Implementar halt() correcto en DS3231 (EOSC)

Si quieres hacerlo “bien”:

• halt(true) ⇒ poner EOSC=1 (deshabilita oscilador)

• halt(false) ⇒ limpiar EOSC=0 (habilita)

Regla: EOSC está en 0x0E, bit 7.

Esto mantiene el contrato de tu API y evita sorpresas.

Implicación de hardware si pasas a DS3231

• No necesitas cristal externo (te ahorras componente y sensibilidad mecánica).

• Mantén pull-ups I2C (o confía en los del Mega si ya existen, pero mejor en la shield).

• Alimentación VBAT con CR2032 igual.

• Muy recomendable: 100 nF de desacoplo pegado al chip/módulo.

Recomendación final (por coste/fiabilidad y sin rehacer firmware)

• Si tu objetivo es shield barata y rápida: DS1307 y listo.

• Si tu objetivo es producto más robusto sin reescribir el proyecto: DS3231 + B1 (halt NO-OP) o B2 (EOSC).

Si me dices cuál de los dos caminos eliges (A o B), te paso el parche exacto (diff) listo para aplicar en el repo, y además te marco qué parte del esquemático/PCB cambia (muy poco: básicamente el bloque RTC y el footprint si usas módulo).

Tienes razón: “módulo” abarata y simplifica, pero te mete riesgo de suministro si el footprint no es un estándar de facto. La forma profesional de resolverlo no es “confiar”, sino diseñar para compatibilidad mecánica/eléctrica con más de una opción y, si hace falta, tener un “Plan B” con IC discreto.

Aquí va cómo lo haría para Ethernet + RF manteniendo facilidad de fabricación y reduciendo riesgo de quedarte sin módulos.

1) Ethernet: cómo hacerlo sin casarte con un módulo raro

Opción recomendada: “módulo sin conector” + RJ45 en tu PCB

En lugar de depender de un módulo con RJ45 integrado (muchos cambian el footprint), usa un módulo W5500/W5100 tipo “breakout” de 2×N pines sin el conector, y montas tú el RJ45 (o MagJack) en tu placa.

Ventajas

• Los breakouts W5500 más comunes comparten un patrón muy similar: 2 filas 2.54 mm con SPI + 3V3 + GND + INT/RST.

• El RJ45 lo controlas tú: mecánica estable.

Cómo lo garantizas

• Diseña un footprint “universal”: pads alargados + “doble taladro” (dos posiciones alternativas) para cubrir los 2–3 breakouts más comunes.

• Deja SPI con jumpers 0Ω (MOSI/MISO/SCK/CS/INT/RST) para re-map si algún módulo trae INT en otro pin.

Alternativa robusta: W5500 en chip + MagJack (sin módulos)

Si quieres eliminar el riesgo de módulo al 100%:

• Montas W5500 QFN (o W5100 LQFP, más fácil de soldar), y un MagJack estándar (Halo, Pulse, etc.).

Pero: sube la dificultad de fabricación (QFN) y el layout (señal + magnetics). Aun así, con W5100 LQFP y buen layout 2 capas se puede, pero ya no es “low-risk”.

Mi recomendación práctica para <200 USD y fácil de fabricar:
Footprint universal para breakout W5500 + RJ45 en tu PCB. Es el punto medio más sólido.

2) RF: aquí sí existe un “cuasi-estándar” (HopeRF / RFM)

Aunque no sea “Arduino standard”, los módulos HopeRF RFMxx (RFM12B, RFM69, RFM95/96 LoRa) comparten dos cosas muy valiosas:

• Encapsulado y pad-out muy parecido entre familias (sobre todo dentro de la misma “generación”).

• Se venden por múltiples canales/clones.

Lo profesional: “footprint compatible por familia + adaptador barato”

Hazlo en dos niveles:

Nivel A — Footprint base RFM (pad 2×8 o SMD castellated según módulo)

• Diseña footprint para el RFM12B/RFM69 (los de 16 pines) si tu código está en RFM12B como el esquema indica.

• Si más adelante quieres LoRa (RFM95), normalmente cambia el footprint. Solución:

Nivel B — “socket de 2×8 2.54mm” como interfaz estable

Colocas un header 2×8 o 2×9 2.54mm con señales:

• 3V3, GND

• SPI: SCK/MOSI/MISO

• NSS/CS, RESET, DIO0/IRQ (y DIO1 opcional)

Y si el día de mañana cambias de módulo, haces una plaquita adaptadora de 2 euros (PCB pequeña) que convierte ese header a cualquier RF.

Esto te da estabilidad mecánica: tu shield no cambia nunca; cambias la “mezzanine” RF.

3) Cómo “garantizar” suministro de verdad (sin prometer imposibles)

No existe garantía absoluta, pero sí puedes diseñar para que el riesgo sea aceptable:

1. Selecciona 2–3 módulos candidatos por bloque (Ethernet y RF) y haz un footprint que los cubra (o un header estable + adaptadores).

2. Evita footprints únicos: todo a 2.54 mm o castellated estándar.

3. No dependas del pinout exacto: añade 0Ω/jumpers para CS/INT/RST/IRQ.

4. Documenta equivalencias en la propia serigrafía (por ejemplo: “ETH_INT / ETH_RST / ETH_CS” y “RF_IRQ / RF_CS”).

5. Plan B en PCB: deja “landing pads” para soldar directamente un módulo alternativo por cable o header si un proveedor falla.

4) Mi propuesta concreta para tu proyecto Ferduino

• Ethernet: interfaz SPI hacia un footprint universal de breakout W5500 (2×8/2×10) + RJ45/MagJack fijo en tu PCB o directamente un RJ45 integrado si el módulo lo trae, pero sin depender de él para mecánica.

• RF: header 2×8 con señales SPI + IRQ + RST + 3V3/GND y adaptador a RFM12B (para mantener el código actual).

Esto mantiene el diseño “fabricable” y barato, y te permite cambiar de proveedor sin rediseñar la shield.

Si quieres, lo siguiente que hago es:

• listar las señales mínimas que necesita tu firmware para Ethernet (CS/INT/RST + SPI) y RF (CS/IRQ/RST + SPI),

• y proponerte un footprint universal (dimensiones, taladros alternativos, jumpers) para que puedas comprar módulos distintos y que todos entren.

Sí: quitar toda la circuitería del Mega integrado es, con diferencia, el mayor recorte de coste y complejidad. En la placa original estás pagando (y fabricando) prácticamente otro Arduino completo dentro: ATmega2560, ATmega16U2/USB, cristal, reguladores, protección USB, conectores, etc. Al pasar a shield, todo eso desaparece.

En qué se traduce (coste y fabricación)

• BOM baja: te quitas 2 micros, USB, osciladores, parte de regulación, y mucho pasivo asociado.

• PCB más simple: menos densidad, menos pistas críticas, menos capas “por obligación”.

• Ensamblaje más fácil: menos SMD fino y menos puntos de fallo.

• Test más rápido: ya no hay que validar USB/bootloader/16U2.

En un escenario típico, ese bloque “Arduino completo” puede representar tranquilamente decenas de dólares en BOM y bastante en mano de obra/retrabajo (sobre todo si no haces volumen). Así que sí: solo con ese cambio ya te acercas mucho al objetivo de <200 USD.

Ojo con el “nuevo” coste dominante

Cuando eliminas el Mega, el coste pasa a estar dominado por:

1. Relés y conectores (DB25/DB9/BNC/borneras)

2. Ethernet (módulo o chip + RJ45/magnetics)

3. Drivers de potencia (MOSFETs, disipación, protecciones)

4. Caja/cableado si lo incluyes en producto final

Ahí es donde conviene optimizar para asegurar margen.

Qué haría yo para asegurar el ahorro sin sorpresas

• Mantener 2 capas y componentes “amables” (0603/0805, THT para conectores).

• Decidir pronto si Ethernet será módulo (más barato de ensamblar) o chip (más control, más esfuerzo).

• Dejar el RTC como DS1307 si quieres cero cambios de firmware, o DS3231 con un parche pequeño si priorizas precisión.

Si quieres, puedo sacarte un presupuesto BOM por bloques (RTC, Ethernet, RF, relés, conectores, regulación) usando lo que ya aparece en tus PDFs, para ver rápidamente dónde se va el dinero y qué recortes tienen mejor impacto.

Sí, es viable portarlo a Arduino Due, pero no es un “recompile y ya”. La viabilidad depende de cuánto del proyecto esté apoyado en:

• Arduino API estándar (digitalWrite, pinMode, SPI, Wire, etc.) → fácil/moderado.

• Acceso directo a registros AVR / PROGMEM / EEPROM AVR / timers AVR → trabajo serio (y ahí es donde normalmente se atascan estos ports).

En tu caso (controlador con Ethernet SPI, RF SPI, RTC I2C, DS18B20 1-Wire, relés/driver ULN, PWM, etc.), la arquitectura es portable, pero hay 3 puntos críticos por el salto Mega→Due.

1) Qué cambia al pasar a Due (SAM3X8E)

1) Niveles eléctricos

• Due es 3.3 V y muchos pines NO son tolerantes a 5 V.

• Si tu shield original asume 5 V (relés, ULN2803 con bobina 5 V, entradas con pullups a 5 V, BNC con acondicionamiento a 5 V, etc.), necesitas:

  • level shifting, o

  • rediseñar periféricos a 3.3 V donde se pueda, o

  • aislar (opto/driver) y mantener 5 V solo en potencia.

Esto es el mayor “coste oculto” del port.

2) Pinout y periféricos hardware

• SPI/I2C existen, pero los pines físicos y algunas sutilezas (interrupts, timers/PWM) cambian.

• Si el firmware usa muchas asignaciones “fijas” del Mega (y lo hace), hay que crear una capa de mapeo.

3) Librerías “AVR-dependientes”

Lo típico que rompe:

• PROGMEM, pgm_read_xxx

• EEPROM.h (en Due no hay EEPROM real; se emula en flash)

• Cualquier código que toque PORTx, DDRx, PINx

• Timer/interrupt setup “a mano” pensando en AVR

2) Qué partes del proyecto son “portables” con poco dolor

Normalmente estas salen bastante directas en Due si usas librerías correctas:

• RTC por I2C (DS1307/DS3231): vía Wire → bien.

• Ethernet W5100/W5500 por SPI: Ethernet.h tiene soporte en Due → bien (si no hay hacks AVR).

• SD por SPI: suele ir bien.

• Relés / salidas digitales: bien si todo está en digitalWrite.

• Sensores DS18B20: depende de la librería OneWire. Hay implementaciones compatibles con Due, pero si tu proyecto usa una versión antigua, tocará actualizar.

3) Zonas de riesgo alto en este tipo de firmware (donde un HAL ayuda mucho)

1. RF (RFM12B)
   Muchos drivers RFM12B antiguos usan:

   • interrupciones por pin concretas,

   • timing fino,

   • y a veces acceso rápido a puertos AVR.

   Si tu stack RF es “bajo nivel” y AVR-centric, aquí suele estar el mayor trabajo. Si en cambio está basado en SPI + attachInterrupt sin trucos AVR, es más llevadero.

2. PWM / temporización de bombas / wavemaker
   Si el código configura timers AVR para frecuencias concretas, en Due tendrás que reimplementar esa parte con:

   • analogWrite (si te vale),

   • o PWM avanzado del SAM3X,

   • o un scheduler por millis() si no necesitas frecuencia exacta.

3. Persistencia (EEPROM)
   Si guardas settings en EEPROM AVR, en Due toca:

   • usar “EEPROM emulada” (hay librerías),

   • o migrar a un storage propio en flash.

4) Sí: implementar una HAL para portarlo a más placas es buena idea

La clave es definir un “Board Support Package” (BSP) con dos niveles:

Nivel A — HAL mínima (portable)

Funciones/servicios que TU código usa y que cada placa implementa:

• GPIO:

  • pinModeOut(pin), pinModeInPullup(pin)

  • write(pin, value), read(pin)

• SPI:

  • spiBegin(), spiTxRx(buf)

  • spiSelect(device), spiDeselect(device) con configuración por dispositivo (clock, mode)

• I2C:

  • i2cRead(addr, reg, buf), i2cWrite(addr, reg, data)

• Timing:

  • nowMs(), delayMs()

  • opcional: scheduleEveryXms(task)

• Persistencia:

  • cfgRead(key), cfgWrite(key)

• Debug:

  • logPrint(...)

Nivel B — “Pin map” por placa (lo que más te interesa)

Un archivo tipo board_mega2560.h y board_due.h con:

• definición de pines funcionales (PIN_ETH_CS, PIN_RF_IRQ, PIN_RELAY1, etc.)

• capacidades (si hay ADC de X bits, PWM en tal pin, etc.)

• opciones eléctricas (3.3/5 V)

Tu firmware deja de hablar en “D22, A15…” y habla en “RELAY_RETURN, ETH_CS…”.

Con eso, portar a otra placa pasa a ser crear un pinmap y ajustar 2–3 drivers conflictivos, no reescribir todo.

5) Qué haría yo como plan técnico (sin rehacer el proyecto entero)

1. Congelar funcionalidad en Mega (compilar y listar: periféricos usados, pines, librerías).

2. Buscar y eliminar dependencias AVR:

   • PORTx, PROGMEM, EEPROM, timers directos.

3. Crear HAL + pinmap sin tocar lógica de negocio.

4. Port “fácil” primero: RTC, Ethernet, UI, relés.

5. Port “difícil” después: RF, PWM/timers, OneWire, storage.

Veredicto de viabilidad

• Port a Due: viable, pero con trabajo medio/alto principalmente por 3.3 V + RF/timers/EEPROM según cómo estén implementados.

• HAL para multi-placa: muy recomendable; te baja deuda técnica y te permite que el hardware (shield) no te ate a una sola familia.

Si quieres, el siguiente paso más útil es que te diga exactamente qué partes del código actual son AVR-dependientes (las que romperían en Due) y te proponga una estructura de carpetas HAL/BSP concreta para este proyecto. Con eso ya puedes estimar esfuerzo real y decidir si vale la pena.

Hecho. He revisado el árbol del proyecto que pasaste (carpeta Ferduino_Aquarium_Controller y librerías incluidas) buscando dependencias AVR que romperían al compilar/ejecutar en Arduino Due (SAM3X, 3.3 V) y, en paralelo, qué conviene meter detrás de una HAL/BSP para poder portar a más placas.

1) Hallazgos: qué es portable y qué NO

A. El “core” del controlador es bastante portable (buena noticia)

En Ferduino_Aquarium_Controller/src no hay acceso directo a registros de puerto AVR (PORTx/DDRx/PINx), ni ISRs/timers AVR configurados a mano (al menos en el core). Lo principal es Arduino API + librerías típicas:

• Wire, SPI/Ethernet, SdFat, DallasTemperature/OneWire, UTFT/URTouch (si se usa TFT), PCF8574, etc.
  Esto es una base razonable para Due si ajustas librerías y pines.

B. Hay 4 “bloques” que sí te condicionan el port

1) Watchdog AVR (rompe en Due tal cual)

En src/Include/Library.h se incluye #include <avr/wdt.h> y el código usa wdt_enable(WDTO_8S), wdt_disable(), wdt_reset() en varios módulos:

• src/Modules/Setup.h, Loop.h, Clima.h, ProcessMyTouch.h, y un #define WATCHDOG en Configuration.h.

En Due esto no compila con esa cabecera, y aunque lo adaptes, el watchdog del SAM3X no tiene la misma API.

✅ Solución: encapsularlo en HAL (ver sección 2).

2) PROGMEM / pgmspace AVR (rompe al incluir <avr/pgmspace.h>)

En src/Include/Library.h se incluye #include <avr/pgmspace.h> y se usan macros/funciones tipo:

• strcpy_P, pgm_read_word_near, etc. (por ejemplo, se ve en src/Modules/ProcessMyTouch.h).

En Due no existe <avr/pgmspace.h> como tal. En ARM normalmente no necesitas PROGMEM; pero el código está escrito para AVR.

✅ Solución: crear un “shim” portable de pgmspace o migrar esas tablas a const normal.

3) EEPROM (Due no tiene EEPROM real; emula en flash y OJO con desgaste)

Hay uso intensivo de EEPROM.write() en src/Modules/Funcoes_EEPROM.h y otros módulos (Setup.h, Menus.h, etc.), con offsets altos (ej. cientos de bytes).
En Due, si usas la EEPROM emulada en flash, no puedes escribir a lo loco cada poco tiempo sin preocuparte por la vida útil.

✅ Solución: HAL de almacenamiento + estrategia (flash con wear leveling / externo I2C EEPROM / FRAM).

4) RF: la librería incluida RFM12B es AVR-hardcore (este es el “stopper” grande)

La librería Bibliotecas/RFM12B/RFM12B.h incluye directamente:

• <avr/io.h>, <avr/eeprom.h>, <avr/sleep.h>
  y usa registros SPI (SPCR, SPSR, SPDR) y puertos AVR (PORTx, etc.) en .h/.cpp.

Esto en Due no es un simple cambio de pines: hay que re-escribir el driver o cambiar de librería/protocolo RF.

✅ Solución: abstraer RF detrás de HAL y escoger una implementación compatible (o reescribir usando SPIClass + attachInterrupt).

2) Propuesta concreta de HAL/BSP para hacerlo portable

La clave es separar 2 cosas:

(1) BSP (Board Support Package) = mapeo de pines + capacidades

Archivos por placa:

• boards/board_mega2560.h

• boards/board_due.h

• (y en el futuro board_stm32.h, etc.)

Contienen:

• PIN_ETH_CS, PIN_ETH_RST, PIN_RF_CS, PIN_RF_IRQ, PIN_RLY1…, PIN_DS18B20_BUS, etc.

• flags: BOARD_VCC_MV = 5000/3300, HAS_EEPROM = 1/0, HAS_DAC, etc.

Así tu lógica deja de decir “A15/D53” y pasa a decir “RF_CS / ETH_CS”.

(2) HAL = API estable para servicios “problemáticos”

Una interfaz mínima (casi todo inline) para:

• Watchdog: hal_wdt_enable(ms), hal_wdt_disable(), hal_wdt_kick()

• Persistencia: hal_nv_read(addr, buf, len), hal_nv_write(addr, buf, len) + versión/CRC

• PROGMEM: hal_pgm_read_ptr(), hal_strcpy_P() o, mejor, redefinir macros en un header común

• SPI select por dispositivo: hal_spi_begin_device(DEV_ETH), hal_spi_begin_device(DEV_RF), hal_spi_end_device()

Con eso, el 80% del port es:

• crear board_due.h

• adaptar hal_* a SAM3X

• y resolver RF + storage.

3) Qué cambios haría ya en el repo (pasos exactos)

Paso 1 — Quitar includes AVR del “include central”

En src/Include/Library.h:

• reemplazar <avr/pgmspace.h> por un header propio tipo hal/pgm_compat.h

• reemplazar <avr/wdt.h> por hal/watchdog.h

Paso 2 — Watchdog portable (fácil)

Crear hal/watchdog.h:

• En Mega: wrappers a wdt_enable/disable/reset

• En Due: opción A (rápida): stubs (no-op) para compilar y probar estabilidad

• En Due: opción B (mejor): implementación real con watchdog SAM3X (si decides usarlo)

Paso 3 — PROGMEM portable (fácil-medio)

Crear hal/pgm_compat.h:

• AVR: incluir <avr/pgmspace.h>

• ARM (Due): definir PROGMEM vacío y mapear strcpy_P a strcpy, pgm_read_word_near a dereferencia segura.
  Esto suele funcionar porque en ARM los const ya viven en flash.

Paso 4 — EEPROM: decidir estrategia (esto sí hay que pensarlo)

Opciones realistas:

1. Seguir con EEPROM emulada de Due si el firmware escribe pocas veces (settings al cambiar menús).
   Si el código escribe muy a menudo (logs, contadores frecuentes), mala idea.

2. Poner en tu shield un I2C EEPROM (24LC256/512) o, mejor, FRAM I2C (MB85RCxx) y mapear ahí hal_nv_*.
   Para un producto, FRAM es una gozada: escrituras “infinitas” y simple.

Yo aquí, por robustez, elegiría FRAM si el presupuesto lo permite; si no, EEPROM externa.

Paso 5 — RF: aquí está el trabajo “de verdad”

Tienes tres rutas:

• Ruta RF-1 (recomendada): sustituir RFM12B por un módulo con librería portable (p.ej. RFM69/RFM95 con librería moderna) y adaptar protocolo.

• Ruta RF-2: mantener RFM12B pero cambiar a un driver portable (si encuentras uno compatible con Due) o migrar a RadioHead si soporta tu módulo.

• Ruta RF-3: reescribir el driver actual para SAM3X (más trabajo, pero control total).

La HAL te permite que el resto del sistema no se entere del cambio.

4) Viabilidad real del port a Due (con lo encontrado)

• Compilar “algo” en Due (sin RF, sin watchdog real, con shim de PROGMEM): muy viable.

• Producto estable en Due: viable si resuelves:

  1. niveles 3.3 V (hardware),

  2. almacenamiento no volátil bien hecho,

  3. RF con driver/librería portable.

5) Qué haría a continuación (para darte un diagnóstico definitivo)

Si quieres, lo siguiente (y más útil) es que te devuelva una lista “tipo auditoría” con:

• todas las llamadas a EEPROM.write/update/read (frecuencia probable y riesgo de desgaste),

• todos los usos de *_P/pgm_read_*,

• y un mapa de pines “funcionales” para construir board_mega2560.h y luego board_due.h.

Puedo hacerlo y dejarte una propuesta de estructura de carpetas (hal/, boards/, drivers/) lista para aplicar.

Sí — sí existen otras placas que puedes usar como alternativa al Arduino Mega 2560, con diferentes balances de potencia, recursos y compatibilidad con shields, aunque cada una tiene sus consideraciones al portear un proyecto como el tuyo. Wikipedia+1

🧠 1) Placas con forma y ecosistema “Mega-like”

✅ Arduino Due

• Forma física y número de I/O muy similar al Mega (54 digitales y 12 analógicos).

• ARM Cortex-M3 a 84 MHz (mucho más rápido que el AVR del Mega) con más SRAM.

• Puede ejecutar muchos sketches de Arduino si abstraes dependencias de 5 V y AVR.

• Ventaja principal: más recursos, más potencia y periféricos.

• Desventaja: lógica 3.3 V (no tolera 5 V directamente) — esto obliga a adaptar niveles en hardware/shield.

• Por su tamaño y pines, en muchos casos puede usar shields diseñados para el Mega si respetan 3.3 V de señal. circuitdigest.com

👉 Si haces una capa HAL adecuada (como mencionamos anteriormente), portarlo es viable y te da más memoria y velocidad.

💡 2) Placas Arduino “Mega form factor” más modernas

⭐ Arduino Giga R1 WiFi (nuevo en la familia Arduino)

• Mantiene compatibilidad de pinout con Mega/Due y, según información reciente, también busca soportar shields con ese factor de forma.

• Incluye mucha más capacidad de procesamiento, Wi-Fi, y pines adicionales útiles para proyectos grandes.

• Está diseñado para ser compatible con accesorios “Mega” — potencial base para proyectos complejos sin reescritura completa del hardware. industrialshields.com

⚠️ En este caso hay que verificar niveles de tensión y compatibilidad de señal con tu shield actual (este tipo de placas nuevas pueden ser estrictas con 3.3 V).

🧩 3) Compatibilidad física y alternativas

➤ Forma compatible con shield (pero distinto micro)

Hay algunas placas ARM o FPGA que también adoptan el form factor Arduino (tamaño y headers), aunque no siempre mantienen todos los pines de Mega:

• Placas SAMD21/SAMD51 (por ejemplo “Arduino Zero”, “Seeeduino Cortex-M0+”) — tienen forma proyectada para shield UNO, no Mega clásico. Wikipedia

• Clones Mega 2560 basados en ATmega2560 — ofrecen simplemente lo mismo que el Mega a menor coste y siguen siendo perfectamente compatibles con tu shield sin cambios. electrocomponentes.es

⚠️ Consideraciones importantes al elegir otra placa

🔌 5 V vs 3.3 V de lógica

• Mega y sus compatibles tradicionales funcionan a 5 V.

• Due y muchas tarjetas modernas (Giga, algunos SAMD) operan a 3.3 V, lo que requiere adaptación de nivel lógico o buffers en tu shield si vas a conectar directamente pines de E/S de 5 V. circuitdigest.com

🛠️ Periféricos y librerías

• El Due y placas similares tienen más recursos pero cambian los periféricos (timers, SPI, I2C). Por eso, repito lo de la HAL: sin esa capa Board Support y abstracción de pines/periféricos, la migración sigue siendo trabajosa.

📌 Shield compatibility real

• La mayoría de shields diseñados para Arduino Uno/Mega R3 integran la norma de pinout físico definido por Arduino.

• Mega/Due comparten ese pinout básico (GPIO, SPI, I2C), sin embargo la tensión y funciones especiales (PWM, timers, etc.) pueden diferir. learn.sparkfun.com

✅ Recomendaciones según tus objetivos

📌 Conclusión

No hay otra placa oficial Arduino con exactamente el mismo pinout que Mega 2560 y lógica 5 V aparte de variantes/compatibles basados en ATmega2560, pero sí hay opciones con la misma forma física y más recursos, como Arduino Due o la nueva Arduino Giga R1 WiFi, que son muy interesantes si estás dispuesto a invertir en la capacidad de adaptación de tu firmware y hardware shield. Wikipedia+1

Si quieres, puedo darte una tabla de comparación técnica de pines/periféricos entre Mega, Due y Giga (o cualquier otra placa Arduino relevante) para ayudarte a decidir cuál encaja mejor con tus necesidades de recursos y compatibilidad.

Perfecto, vamos por partes y con rigor técnico.
Primero la tabla comparativa clara entre las 3 placas y luego la estrategia de hardware para que UNA MISMA SHIELD funcione con las tres, resolviendo el problema 5 V / 3.3 V (que, como bien dices, es el verdadero cuello de botella).

1) Tabla comparativa: Mega 2560 vs Due vs Giga R1 WiFi

Conclusión de la tabla

• Mecánicamente: las tres pueden aceptar una shield tipo Mega.

• El único bloqueo real es eléctrico:
  Mega = 5 V
  Due + Giga = 3.3 V

• Software: solucionable con HAL (ya lo vimos).

• Hardware: solucionable si diseñas la shield correctamente.

Y aquí viene la parte importante 👇

2) Sí: ES POSIBLE usar las 3 placas con UNA SOLA SHIELD

(si el diseño eléctrico se hace bien desde el principio)

La clave es esta idea:

La shield NO debe asumir nunca que el MCU es 5 V
La shield debe ser voltage-agnostic.

Principio fundamental

👉 El microcontrolador SOLO habla a nivel lógico
👉 La shield decide a qué tensión trabaja internamente

3) Arquitectura de shield “universal” 5 V / 3.3 V

🔑 Regla de oro

• Todo lo que va al MCU → 3.3 V compatible

• Todo lo que necesita 5 V → aislado / adaptado

4) Cómo resolver el problema 5 V / 3.3 V por bloques

A) GPIO digitales (relés, ULN, MOSFETs)

Solución estándar y barata ✅

• El MCU NO excita directamente cargas

• Usa:

  • ULN2803 (funciona perfectamente con 3.3 V en la entrada)

  • o MOSFET logic-level (AO3400, IRLML6344, etc.)

➡️ Resultado:

• Mega: 5 V → OK

• Due/Giga: 3.3 V → OK

• Sin level shifter

✔️ Este bloque es trivial de hacer compatible.

B) Entradas digitales (niveles, switches, sensores)

Aquí sí hay que pensar

Solución recomendada:

• Pull-ups a 3.3 V en la shield, no a 5 V

• Entrada tolerante:

  • divisor resistivo

  • o buffer tipo 74LVC (tolerante a 5 V en entrada)

➡️ Mega leerá HIGH a 3.3 V sin problema
➡️ Due/Giga están protegidos

C) SPI / I2C (Ethernet, RF, RTC, SD)

Zona crítica — pero solucionable

I2C

• Pull-ups SIEMPRE a 3.3 V en la shield

• Mega acepta 3.3 V como HIGH → OK

• Due/Giga necesitan 3.3 V → OK

✔️ I2C universal sin conversores

SPI

Tienes dos opciones:

Opción 1 (recomendada)

• Todos los periféricos SPI funcionan a 3.3 V

• Shield genera su propio 3.3 V

• Mega habla SPI a 3.3 V → OK

Opción 2 (más robusta)

• Buffer SPI con 74LVC245 / 74LVC125

• Dirección MCU → periféricos

✔️ Compatible con las 3 placas

D) Entradas analógicas (ADC, BNC, sondas)

Esto es MUY importante en tu proyecto.

Diseño correcto:

• Rango máximo de señal = 3.3 V

• Acondicionamiento analógico (op-amp rail-to-rail a 3.3 V)

• Nunca alimentar un ADC directo a 5 V

➡️ Mega pierde algo de rango, pero gana compatibilidad
➡️ Due/Giga felices
➡️ Hardware único

E) EEPROM / almacenamiento

No depende del MCU si haces esto:

• Coloca FRAM I2C (3.3 V) en la shield

• MCU solo accede por I2C

✔️ Mega / Due / Giga idénticos
✔️ Sin desgaste
✔️ Independiente de plataforma

5) Selección automática de placa (sin jumpers)

Puedes incluso hacer la shield auto-detectable:

Método simple

• Detectar si el pin IOREF = 5 V o 3.3 V

• IOREF existe en Mega, Due y Giga

Uso:

• IOREF = referencia lógica

• Buffers alimentados desde IOREF

• Pull-ups referenciados a IOREF o a 3.3 V fija

➡️ La shield se “adapta” sola a la placa conectada.

6) Resumen claro (esto es lo importante)

✔️ Sí, puedes usar Mega 2560 + Due + Giga R1 con UNA sola shield
✔️ El software NO es el problema
✔️ El hardware solo es problema si se diseña mal

La receta correcta

• Shield lógica interna a 3.3 V

• Nada conectado directamente al MCU sin:

  • driver,

  • buffer,

  • o adaptación de nivel

• Uso de IOREF

• FRAM externa

• SPI/I2C pensados como buses de 3.3 V

Si quieres, el siguiente paso natural es:
👉 dibujar la arquitectura eléctrica definitiva de la shield “universal”
con bloques y decisiones claras (qué va a 3.3 V, qué a 5 V, qué se aísla).

Ahí es donde el proyecto ya pasa de “portar” a diseño profesional reutilizable.

Vale. Te propongo una arquitectura eléctrica de shield “universal” (Mega 2560 5 V + Due 3.3 V + Giga 3.3 V) que hace que el hardware sea “salvable” y la portabilidad sea básicamente software + pinmap.

Objetivo de diseño

1. No exponer nunca al micro (Due/Giga) a señales > 3.3 V

2. Permitir que el Mega funcione sin penalización seria

3. Mantenerlo fabricable en 2 capas, con componentes comunes, y coste controlado.

1) Dominios de alimentación y referencia lógica

Dominios

• VIN_Power (12 V): relés, bombas, LEDs, etc.

• +5V_Power: bobinas 5 V (si usas relés 5 V), periféricos legacy.

• +3V3_Logic: todo lo digital “sensible” (Ethernet, RF, I2C, SPI, FRAM, RTC si procede).

• VIO (referencia de IO del MCU): tomada de IOREF del header Arduino.

Regla clave

• La shield trabaja internamente a 3.3 V para buses y periféricos.

• VIO solo se usa para:

  • alimentar buffers si decides que sigan al MCU,

  • o para detección de plataforma.

Implementación

• Buck 12→5 (si tienes cargas 5 V relevantes) + LDO/Buck 5→3.3

• Añade medición/diagnóstico: testpoints en 12/5/3.3 y GND.

2) La idea central: buses y periféricos SIEMPRE a 3.3 V

I2C (RTC, expansores, FRAM)

• Pull-ups a 3.3 V SIEMPRE.

• Mega lee HIGH a 3.3 V sin problema.

• Due/Giga quedan protegidos.

Componentes:

• Pull-ups 2.2k–4.7k a 3.3V (según longitud del bus).

• ESD en líneas si salen a conectores.

SPI (Ethernet / RF / SD)

Aquí está el “punto fino”. Dos opciones:

Opción SPI-A (la que yo elegiría)

• Periféricos SPI a 3.3 V.

• MCU → periféricos:

  • En Mega (5V): conversión de nivel hacia abajo en MOSI/SCK/CS (y opcionalmente RESET).

  • En Due/Giga (3.3V): pasan directos.

Cómo hacerlo barato y limpio:

• 74LVC125 / 74LVC245 alimentado a 3.3 V

  • Entradas 5 V tolerantes (familia LVC) y salida 3.3 V → perfecto para bajar nivel desde Mega.

  • Para MISO (3.3V a MCU): normalmente no hace falta buffer; Mega lo lee bien y Due/Giga ya están a 3.3.

Con esto, el SPI se vuelve universal sin jumpers.

Opción SPI-B (más flexible, algo más BOM)

• Buffers bidireccionales o dos bancos de buffers que siguen VIO.

• Yo lo evitaría salvo que tengas casos raros.

3) Entradas/salidas digitales: no dependas de 5 V

Salidas a relés / cargas

• No uses GPIO directo a bobina ni a nada externo.

• Usa drivers:

Relés 5 V:

• ULN2803A (funciona con entradas 3.3 V) + relés 5 V + diodo integrado.

• Si los relés son 12 V, mejor todavía (separas 5 V).

MOSFETs para DC (ventiladores, bombas DC, tiras LED):

• MOSFET N logic-level con gate a 3.3 V (elige uno con Rds_on especificado a Vgs=2.5/3.3).

• Gate resistor + pull-down + TVS/diodos según carga.

Esto te hace 100% compatible con las 3 placas.

Entradas digitales (nivel, pulsadores, alarmas)

• Pull-ups a 3.3 V en shield.

• Protección:

  • resistencia serie (1k–4.7k)

  • TVS/ESD (si cables largos)

  • opcional: 74LVC14 (Schmitt) si hay ruido.

Si esperas señales externas a 5 V (por ejemplo sensores ya cableados a 5 V), entonces:

• 74LVC245/74LVC125 o divisor resistivo + clamp para que nunca supere 3.3V hacia el MCU.

4) Analógicas (BNC, sondas): “3.3 V first”

Este es el otro gran punto donde se suelen romper ports.

Regla

• Todo lo que entra al ADC debe estar limitado a 0–3.3 V.

Implicación

• Mega (10-bit, 0–5 V) perdería “span”, pero es aceptable y te da universalidad.

• Due/Giga (12-bit) compensan con más resolución.

Implementación típica

• Acondicionamiento con op-amp rail-to-rail a 3.3 V.

• Clamp/limit: resistencia + diodos a 3.3/GND o protector específico.

• Filtro RC antiruido.

5) Almacenamiento no volátil: sácalo del MCU

Para que Mega/Due/Giga sean equivalentes y no sufrir EEPROM emulada:

• Añade FRAM I2C 3.3 V en la shield (p. ej. 32–256 kbit según necesidades).

• Mismo código HAL para las 3.

Esto te da:

• escrituras ilimitadas prácticas,

• independencia total de la placa,

• portabilidad real.

6) Detección automática (sin jumpers): usa IOREF

• Lee IOREF del header.

  • Mega: ~5 V

  • Due/Giga: ~3.3 V

Para qué lo usaría:

• Para decidir si habilitas el banco de “level shift down” (Mega) o lo puenteas (3.3).

• Esto se puede hacer de dos formas:

Método simple (cero lógica)

• Diseñas los buffers LVC “siempre activos” y listo.

  • Con Due/Giga (3.3) igual pasan bien.

  • Con Mega (5V) los baja a 3.3.

  • Es lo más robusto.

Método “pro” (si quieres optimizar señal/latencia)

• Usar IOREF para controlar OE de buffers (habilitar/inhabilitar).

• No es necesario para que funcione; solo para “pulir”.

7) Esquema por bloques (texto)

1. Power

   • 12V in → Buck 5V → LDO/Buck 3.3V

   • Separación GND_Power / GND_Logic con unión en estrella

2. MCU Interface

   • Headers Mega footprint

   • IOREF sense (opcional)

3. Digital Buses

   • I2C @3.3V pull-ups

   • SPI peripherals @3.3V

   • SPI level shifting: 74LVC125/245 en MOSI/SCK/CS (y RST)

4. Peripherals

   • Ethernet (W5500/W5100) @3.3V

   • RF @3.3V

   • RTC @3.3V

   • FRAM @3.3V

5. Power Outputs

   • ULN2803 for relays (inputs 3.3 ok)

   • MOSFET stages for DC loads

   • Flyback / TVS / fuses as needed

6. Inputs

   • Digital inputs with 3.3 pull-ups + protection

   • Analog front-end scaled to 3.3

8) Lo que cambia en tu proyecto actual (implicaciones prácticas)

• Si hoy tu shield asume 5 V para:

  • pull-ups I2C,

  • periféricos SPI 5 V,

  • entradas analógicas 0–5,

  • sensores que “vuelven” 5 V,

…lo “universal” es:

• pasarlo todo a 3.3 V en la shield y bajar desde Mega con LVC donde haga falta.

9) Decisiones que necesito tomar yo (sin preguntarte) para dejarlo cerrado

Si yo tuviera que fijarlo ya, haría esto:

• Periféricos digitales (ETH/RF/FRAM/RTC): 3.3 V

• I2C pull-ups a 3.3 V

• SPI downshift con 74LVC125/245 (siempre presente)

• Entradas externas: protección + Schmitt donde aplique

• Analógicas: rango 0–3.3 V

• Relés: ULN2803 (bobina 5 V o 12 V según tu fuente)

• FRAM I2C como NVM

Con esto, una sola shield vale para Mega/Due/Giga y el “problema insalvable” 5V/3.3V deja de existir.

Si quieres, el siguiente paso es aterrizarlo a un checklist de esquemático (qué chips exactos entran, cuántos canales de level shift para SPI, dónde poner ESD, valores de pull-ups/series) y te lo dejo listo para pasar a KiCad/Altium.

No.
Y esta es la clave eléctrica que hace posible todo lo que hemos planteado.

Voy a responderte con números, no con “depende”.

Respuesta corta (pero correcta)

👉 Un “1” lógico de 3.3 V NO es un 0 para lógica de 5 V
👉 Para Arduino Mega 2560 (ATmega2560), 3.3 V es un 1 lógico perfectamente válido.

Por qué (con especificaciones, no opiniones)

ATmega2560 (Arduino Mega)

Según la hoja de datos del ATmega2560:

• V_IH (Input High Voltage mínimo) ≈ 0.6 × Vcc

• Si Vcc = 5.0 V
  → V_IH(min) ≈ 3.0 V

📌 Entonces:

👉 3.3 V > 3.0 V ⇒ HIGH garantizado

En placas 3.3 V (Due / Giga)

• NO toleran 5 V en entrada

• Umbral típico:

  • V_IH ≈ 0.7 × 3.3 V ≈ 2.3 V

• Por eso:

  • 3.3 V → OK

  • 5 V → daño

Conclusión eléctrica fundamental

Por eso el diseño correcto es:

Todo lo que sale de la shield hacia el MCU debe ser ≤3.3 V

Implicación directa para tu shield universal

• I2C pull-ups a 3.3 V → Mega lee HIGH sin problema

• MISO SPI a 3.3 V → Mega lo lee HIGH sin problema

• Salidas digitales desde shield a MCU a 3.3 V → OK

• Entradas digitales del MCU desde sensores → deben limitarse a 3.3 V

Y solo necesitas level shifting en una dirección:

• MCU (Mega 5 V) → shield 3.3 V

Por qué esto es práctica estándar (no teoría)

Es exactamente lo que hacen:

• Shields modernos “5V/3V3 compatible”

• Placas con IOREF

• Módulos Ethernet / SD / RF actuales

Arduino lleva años recomendando:

“Use IOREF and design shields to be logic-level independent”.

Resumen en una frase

👉 3.3 V es un “1” lógico válido para un sistema de 5 V,
👉 pero 5 V NO es válido para un sistema de 3.3 V.

Por eso la arquitectura que te propuse no es un apaño, es la forma correcta y profesional de hacerlo universal.

Si quieres, en el siguiente mensaje te puedo dibujar (en texto) un ejemplo concreto de SPI universal con Mega/Due/Giga para que lo veas “pin a pin”.

Sí, se puede cambiar la TFT “de bus paralelo” del proyecto a una pantalla más moderna que use SPI (o incluso UART tipo HMI), pero no es un cambio de “librería y listo”: en este firmware la pantalla es parte del core (menús, botones, redibujados, touch), así que hay que replantear la capa UI.

Aun así, técnicamente es un movimiento muy sensato, sobre todo si quieres que la shield sea compatible Mega/Due/Giga y reducir pines.

1) Qué usa hoy Ferduino y por qué “consume tantos pines”

El proyecto está hecho para TFT + touch usando UTFT + URTouch (RinkyDink). URTouch está pensado como add-on de UTFT para pantallas TFT que suelen ser paralelas (8/16-bit), que por naturaleza se comen muchos GPIO. rinkydinkelectronics.com

2) Opciones de pantalla “moderna” con menos pines

Opción A — TFT SPI “clásica” (ILI9341 / ILI9488 / ST7789, etc.)

Interfaz: SPI (4–6 señales) + opcional SD por SPI compartido
Touch:

• Resistivo con controlador XPT2046 por SPI (muy común)

• Capacitivo con FT6206 por I2C (en algunas pantallas)

Librerías recomendables:

• Adafruit_GFX + Adafruit_ILI9341 (muy común y mantenida) GitHub

Ventajas

• Muchísimos módulos disponibles (2.4"–3.5")

• Menos pines (ideal para tu objetivo)

• Fácil de hacer “universal” 3.3 V (Mega lee 3.3 como HIGH)

Inconvenientes

• En Mega el SPI es relativamente lento: si el firmware redibuja pantalla completa con frecuencia, se notará (parpadeo/latencia).

• Hay que adaptar bastante la UI para evitar “full refresh”; conviene “dirty rectangles” (redibujo parcial).

Opción B — Controlador gráfico externo (RA8875 / SSD1963)

Interfaz: SPI o paralelo reducido, pero el chip hace mucha “aceleración” (rectángulos, texto, etc.)

Ventajas

• Mucho mejor rendimiento de UI que una TFT SPI “simple”, especialmente con AVR.

• Puedes usar pantallas más grandes (5", 7") con mejor experiencia.

Inconvenientes

• BOM más caro que ILI9341/9488.

• Placas/módulos menos “commodity”.

Opción C — HMI por UART (Nextion / similar)

Interfaz: 2 pines (TX/RX) + alimentación

Ventajas

• Casi cero pines y cero carga gráfica para el MCU.

• UI se diseña en el entorno del HMI; el MCU solo intercambia eventos/valores.

Inconvenientes

• Cambias por completo el enfoque: la UI deja de ser “dibujada” por tu firmware.

• Dependencia fuerte del proveedor y del flujo de diseño de pantallas.

Opción D — I2C (pantalla gráfica “real”)

Para TFT a color, I2C no es práctico (demasiado lento). I2C encaja para OLED pequeñas monocromas, no para una UI como Ferduino.

3) Sobre librerías “rápidas” tipo TFT_eSPI / LovyanGFX

• TFT_eSPI está muy optimizada para micros 32-bit (ESP32/RP2040/STM32…) y en su documentación se deja claro que requiere un procesador 32-bit para el enfoque de rendimiento que persigue. doc-tft-espi.readthedocs.io+1
  → Para Mega no es la opción típica (puede compilar en algunos entornos, pero no es su foco).

• LovyanGFX declara compatibilidad con arquitecturas como esp32/esp8266/samd/rp2040/mbed, no AVR. docs.arduino.cc

Traducción práctica:

• Si te quedas en Mega, lo más estable es Adafruit_GFX + driver específico.

• Si migras a Due/Giga, ya tienes más margen para librerías “rápidas”, pero hay que validar compatibilidad concreta con esa placa/pantalla (hay hilos de problemas de SPI con Giga y ciertas librerías). Arduino Forum+1

4) Lo importante: cómo lo integras en TU proyecto sin reescribirlo 3 veces

La forma correcta es meter una HAL de Display/Touch (igual que hablamos para la placa), y encapsular UTFT/URTouch.

Display HAL mínima (suficiente para Ferduino)

• begin()

• setRotation()

• fillScreen(color)

• fillRect(x,y,w,h,color)

• drawRect(...)

• drawText(x,y,text,font,color,bg)

• drawBitmap(...) (si usas iconos)

• flush() (si quieres buffering opcional)

Touch HAL mínima

• touchAvailable()

• touchRead(&x,&y)

• calibration (o matriz de calibración)

Con eso haces 2 “backends”:

1. Backend UTFT/URTouch (para mantener el proyecto funcionando mientras migras)

2. Backend Adafruit_GFX + ILI9341 + (XPT2046 o FT6206)

Así el 80–90% del código de menús/botones se mantiene.

5) Ventajas e inconvenientes reales en Ferduino

Ventajas de pasar a SPI (en tu caso)

• Liberas muchísimos pines, que te ayuda para:

  • compatibilidad con otras placas,

  • shield más limpia,

  • añadir level shifting y buses comunes (SPI/I2C).

• Más fácil de hacer universal 3.3/5 V.

• Módulos más fáciles de conseguir que algunas TFT paralelas específicas.

Inconvenientes a vigilar

• Rendimiento en Mega: si tu UI redibuja mucho, tendrás que optimizar.

• Trabajo de migración: hay que adaptar el modelo de dibujo (fuentes, bitmaps, etc.) y el touch.

6) Recomendación concreta para este proyecto

Si quieres un cambio razonable y “industrializable”:

1. Pantalla SPI ILI9341/ILI9488 + XPT2046 (resistiva)

2. Librerías: Adafruit_GFX + Adafruit_ILI9341 GitHub

3. Crear HAL de display/touch y migrar por capas:

   • primero que “pinte algo” equivalente,

   • luego menús,

   • luego touch + calibración.

Si en cambio quieres pantalla grande tipo 5" como en el ecosistema Ferduino, entonces consideraría RA8875/SSD1963 para no sufrir en Mega.

Si me dices qué tamaño/uso quieres (por ejemplo: 2.8" 320×240, 3.5", 5"), te propongo 2–3 modelos concretos (controlador + touch) y te indico exactamente:

• qué pines SPI/I2C usarías,

• cómo compartir SPI con Ethernet/SD sin conflictos (CS),

• y qué cambios habría que hacer en la UI para que el rendimiento en Mega no se degrade.

Sí: para una 2.8” 320×240 lo más razonable es pasarte a SPI (ILI9341/ILI9488/ST7789), y para la parte “servidor remoto Ferduino.com” lo ideal es exactamente lo que dices: meter una HAL de comunicaciones y ofrecer MQTT nativo + Home Assistant (con Discovery).

A continuación te dejo una propuesta cerrada (pantalla + HAL UI + HAL comunicaciones) con ventajas/inconvenientes y librerías reales.

1) Pantalla 2.8” 320×240 moderna con pocos pines

Opción recomendada (equilibrada y común)

TFT SPI con controlador ILI9341 (320×240) + touch

• TFT: ILI9341 por SPI

• Touch resistivo: controlador XPT2046 por SPI (muy común en 2.8”)

• Touch capacitivo (alternativa): FT6206 por I2C (menos común en 2.8”, más en 3.5+)

Librerías

• Adafruit_GFX + Adafruit_ILI9341 (probada y mantenida; menciona explícitamente 2.8" SPI). GitHub+2adafruit.github.io+2
  Para touch, típicamente:

• XPT2046: hay varias librerías; si quieres algo muy estable, podemos encapsular el driver en tu HAL y cambiarlo sin tocar UI.

Ventajas

• Bajas de ~12–20 pines a ~5–7 pines (SPI: SCK/MOSI/MISO + CS + DC + RST; touch añade CS/IRQ si aplica).

• Mucho más compatible con Mega/Due/Giga (si haces todo a 3.3 V).

• Módulos disponibles y fáciles de reemplazar.

Inconvenientes (los reales)

• Rendimiento en Mega: SPI en AVR puede sentirse más lento si redibujas mucho. Solución: redibujado parcial (“dirty rectangles”) y evitar pantallazos completos.

• Migración de UI: UTFT/URTouch no es plug-and-play con Adafruit_GFX; conviene HAL de display/touch.

2) Cómo lo integraría en TU proyecto: HAL de UI (sin reescribir todo)

Objetivo

Que el firmware no “se case” con UTFT/URTouch ni con una pantalla concreta.

Interfaz HAL mínima que te cubre Ferduino

DisplayHAL

• begin()

• fillScreen(color)

• fillRect(x,y,w,h,color)

• drawRect(...)

• drawText(x,y,const char*)

• drawBitmap(x,y,...) (si hay iconos)

• setFont(id) / setTextColor(fg,bg)

TouchHAL

• available()

• read(&x,&y)

• calibrate() o matriz de calibración fija

Luego haces 2 backends:

1. backend actual UTFT/URTouch (para que siga funcionando)

2. backend nuevo Adafruit_GFX + ILI9341 (+ XPT2046/FT6206)

Así el “cambio de pantalla” se vuelve un cambio de backend, no un refactor infinito.

3) Comunicaciones: HAL para “servidor” y salto a MQTT/Home Assistant

Lo que propones es el enfoque correcto: desacoplar la lógica del acuario del transporte (Ferduino.com vs MQTT vs lo que venga).

CommHAL (diseño práctico)

• begin()

• loop() (mantener conexión, reconectar)

• publishState(topicOrKey, payload)

• subscribeCommands() + callback (para setpoints, relés, etc.)

• timeSync() opcional (si antes dependías del servidor para hora)

Backends:

1. FerduinoCloudBackend (mantener compatibilidad)

2. MQTTBackend

3. (futuro) HTTP/REST, WebSocket, etc.

4) MQTT + Home Assistant con Auto Discovery (lo “espectacular”)

Home Assistant soporta MQTT integration y MQTT Discovery, donde el dispositivo publica mensajes “config” en topics especiales (homeassistant/.../config) y HA crea entidades automáticamente. Home Assistant+1

Qué conseguirías

• Entidades auto-creadas: sensores (temp, pH si aplica), switches (relés), numbers (setpoints), selects (modos), etc.

• Integración limpia con HA, dashboards, automatizaciones.

Diseño recomendado de topics (robusto)

• Base topic del dispositivo:
  ferduino/<device_id>/...

• Estado:
  ferduino/<device_id>/state (JSON agregado) o topics por entidad.

• Comandos:
  ferduino/<device_id>/cmd/...

Discovery (patrón típico)

Publicas (retain) por entidad:

• homeassistant/sensor/<device_id>/temp1/config

• homeassistant/switch/<device_id>/relay1/config
  etc., con payload JSON (incluyendo state_topic, command_topic, unique_id, bloque device, etc.). Home Assistant+1

Detalles importantes para que sea sólido:

• Publica discovery en arranque y cuando HA “nace” (birth message). HA recomienda usar el birth message trigger para reenviar discovery. Home Assistant

• Usa retain en los config para que HA recuerde las entidades.

• Estructura device consistente para agrupar entidades en un solo dispositivo en HA.

Librería MQTT en Arduino (probada)

• PubSubClient es el estándar de facto en Arduino para MQTT. GitHub
  Funciona con Ethernet (W5100/W5500) y te vale para Mega/Due/Giga (en Giga además puedes ir por Wi-Fi).

5) Implicaciones/limitaciones en Mega vs Due vs Giga

• Mega: RAM limitada → mejor no publicar JSON enormes ni usar buffers gigantes. PubSubClient también requiere un buffer (configurable); discovery muy largo puede necesitar ajustar tamaño o fragmentar por entidad.

• Due/Giga: mucha más RAM → puedes hacer discovery más rico (atributos, device triggers, etc.).

Mi recomendación para empezar:

• En Mega: entidades “core” (temp, relés, alarmas, setpoints principales).

• En Due/Giga: añade el resto (sensores extra, diagnósticos, métricas).

6) Recomendación concreta “lista para ejecutar” para tu caso

Pantalla

• 2.8" ILI9341 SPI + touch XPT2046

• Migración por HAL con backend doble (UTFT primero, luego GFX)

Comunicaciones

• Implementar CommHAL con dos backends:

  1. MQTT (prioridad)

  2. Ferduino.com (opcional legado)

• MQTT usando PubSubClient GitHub

• Home Assistant Discovery según docs MQTT de HA Home Assistant+1

Si quieres, el siguiente paso útil (sin teoría) es que me digas qué entidades quieres en Home Assistant (mínimo viable):

• temperaturas (cuántas),

• relés (cuántos),

• setpoints (calefactor/refrigeración),

• alarmas,

• modo auto/manual,

y te devuelvo:

1. lista exacta de topics

2. payloads de discovery (sensor/switch/number)

3. esqueleto de CommHAL + backend MQTT adaptado a tu estructura actual del proyecto.

Sí, se puede hacerlo “todo”, pero para que sea mantenible (y no te explote la RAM del Mega ni el tamaño de paquetes MQTT), hay que diseñarlo con arquitectura de entidades + HAL + generación de discovery bien pensada.

A continuación te dejo una arquitectura completa (UI + comunicaciones) y un catálogo de entidades “full” con MQTT Discovery para Home Assistant.

Arquitectura objetivo

Capas

1. Core (lógica acuario): sensores, setpoints, alarmas, modos, schedulers.

2. HAL de IO/Placa: pines, timers, storage, etc. (lo que ya hablamos).

3. HAL de UI: display + touch (UTFT/URTouch vs ILI9341+XPT2046).

4. HAL de Comunicaciones:

   • backend “legacy Ferduino cloud”

   • backend MQTT + HA Discovery

Así, cambiar pantalla o servidor es cambiar backend, no reescribir el core.

Pantalla 2.8" 320×240 SPI (reemplazo “moderno”)

Recomendación concreta

• ILI9341 SPI (320×240) + Adafruit_GFX + Adafruit_ILI9341 Home Assistant+1

• Touch:

  • Resistivo: XPT2046 (SPI, súper común en 2.8")

  • (Si fuese capacitivo: FT6206 I2C, pero menos típico en 2.8")

Ventajas

• Pines: pasas de bus paralelo (muchísimos GPIO) a SPI compartido (SCK/MOSI/MISO + CS por dispositivo).

• Hardware universal 3.3 V: ideal para Mega/Due/Giga.

Inconvenientes

• En Mega, SPI puede sentirse más lento → hay que evitar “redibujar todo”; usar redibujado parcial.

Comunicaciones: MQTT + Home Assistant Discovery (full)

Home Assistant soporta MQTT y auto-creación de entidades vía “discovery config topics” y unique_id + bloque device. Home Assistant+3Home Assistant+3Home Assistant+3

Reglas clave para que “todo” funcione bien

• Publicar discovery (retain) en homeassistant/<domain>/<object_id>/config

• Incluir unique_id (si no, HA no registra bien entidad/dispositivo en discovery). Home Assistant+1

• Implementar availability (LWT/birth) para que HA marque unavailable cuando cae el controlador. Home Assistant+1

• Cuidado con el tamaño de paquete de PubSubClient: el máximo depende del buffer/packet size (por defecto es limitado). GitHub+3GitHub+3Arduino Forum+3
  ⇒ Discovery “full” hay que enviarlo por entidades, con payloads razonables (no un monstruo de 5 KB).

Librería MQTT

• PubSubClient es el estándar en Arduino. GitHub+3pubsubclient.knolleary.net+3GitHub+3

Catálogo “LO QUIERO TODO” (entidades HA)

Voy a estructurarlo como lo haría en producción: por dominios HA.

1) sensor (lecturas)

• Temperaturas: temp_1, temp_2, temp_3 (°C)

• Estado red: uptime_s, free_ram (si aplica), fw_version

• Consumos/diagnóstico si existen: heater_duty, fan_pwm, etc.

• Si el proyecto los soporta: ph, orp, salinity, tds, etc.

2) binary_sensor (contactos/estados booleanos)

• Nivel alto/bajo (ATO, sump): level_low, level_high

• Alarmas activas: alarm_overtemp, alarm_leak, alarm_pump_fail

• Estado de red: connected (aunque availability ya cubre parte)

3) switch (actuadores ON/OFF)

• Relés: relay_1...relay_n (heater, skimmer, return, lights, ATO pump, etc.)

• Modo manual de relé vs automático (si quieres separar control): relay_1_manual_enable

4) number (setpoints y ajustes)

• temp_setpoint, temp_hysteresis

• Setpoints de pH/ORP (si aplica)

• Dosis: ml/día por canal, o tiempo por dosis

• Límites de seguridad: máximos/mínimos

5) select (modos)

• operation_mode: Auto / Manual / Maintenance / Feed

• lighting_profile: Profile1/Profile2 etc. (si el firmware lo tiene)

6) button (acciones puntuales)

• feed_mode_start

• maintenance_start

• reboot_controller

• publish_discovery (útil para reanunciar entidades)

7) text / sensor para “estado UI”

• Mensajes: último error, último evento, etc. (si quieres logging básico)

Convención de topics (robusta y limpia)

• Base: ferduino/<device_id>/

• Estado agregado: ferduino/<device_id>/state (JSON corto) opcional

• Estado por entidad: ferduino/<device_id>/sensor/temp_1, etc.

• Comandos: ferduino/<device_id>/cmd/<entity>

Availability:

• ferduino/<device_id>/availability payload online/offline

HA permite availability en muchas entidades; es una práctica recomendada. Home Assistant+1

Plantillas de Discovery (listas para usar)

A) Sensor (temperatura)

Publicar en:
homeassistant/sensor/<device_id>_temp_1/config

Payload (ejemplo):

json
{
  "name":"Temp 1",
  "state_topic":"ferduino/<device_id>/sensor/temp_1",
  "unit_of_measurement":"°C",
  "device_class":"temperature",
  "unique_id":"<device_id>_temp_1",
  "availability_topic":"ferduino/<device_id>/availability",
  "payload_available":"online",
  "payload_not_available":"offline",
  "device":{
    "identifiers":["<device_id>"],
    "name":"Ferduino Controller",
    "manufacturer":"Ferduino",
    "model":"Aquarium Controller",
    "sw_version":"<fw>"
  }
}

B) Switch (relé)

Topic:
homeassistant/switch/<device_id>_relay1/config

Payload:

json
{
  "name":"Relay 1",
  "state_topic":"ferduino/<device_id>/switch/relay1/state",
  "command_topic":"ferduino/<device_id>/switch/relay1/set",
  "payload_on":"ON",
  "payload_off":"OFF",
  "state_on":"ON",
  "state_off":"OFF",
  "unique_id":"<device_id>_relay1",
  "availability_topic":"ferduino/<device_id>/availability",
  "payload_available":"online",
  "payload_not_available":"offline",
  "device":{"identifiers":["<device_id>"]}
}

(HA documenta unique_id y configuración de MQTT switch; es el patrón correcto.) Home Assistant+1

C) Number (setpoint)

Topic:
homeassistant/number/<device_id>_temp_set/config

Payload:

json
{
  "name":"Temp Setpoint",
  "state_topic":"ferduino/<device_id>/number/temp_set/state",
  "command_topic":"ferduino/<device_id>/number/temp_set/set",
  "min":15,
  "max":35,
  "step":0.1,
  "unit_of_measurement":"°C",
  "mode":"box",
  "unique_id":"<device_id>_temp_set",
  "availability_topic":"ferduino/<device_id>/availability",
  "payload_available":"online",
  "payload_not_available":"offline",
  "device":{"identifiers":["<device_id>"]}
}

D) Binary sensor (nivel)

Topic:
homeassistant/binary_sensor/<device_id>_level_low/config

Payload:

json
{
  "name":"Level Low",
  "state_topic":"ferduino/<device_id>/bin/level_low",
  "payload_on":"ON",
  "payload_off":"OFF",
  "device_class":"problem",
  "unique_id":"<device_id>_level_low",
  "availability_topic":"ferduino/<device_id>/availability",
  "payload_available":"online",
  "payload_not_available":"offline",
  "device":{"identifiers":["<device_id>"]}
}

(HA describe availability para binary_sensor MQTT.) Home Assistant

Cómo hacerlo “todo” sin matar al Mega

1) Discovery por fases (sin pedirte permiso: es la mejor práctica)

• Fase 1 (core): relés + temps + alarmas + modo + setpoints críticos

• Fase 2 (extended): dosificadoras, perfiles, diagnósticos, etc.

En HA es indistinguible para el usuario (aparecen “todas”), pero para tu firmware evita:

• publicar 80 configs enormes en un burst,

• superar el tamaño de paquetes.

2) Tamaño de paquetes PubSubClient

Por defecto el buffer es limitado; puedes aumentarlo, pero hay matices (depende de cómo se configure y del tamaño total topic+payload). GitHub+3Arduino Forum+3pubsubclient.knolleary.net+3
Estrategia segura:

• Mantener payload de discovery “compacto”

• Publicar por entidad

• Evitar JSON gigante de estado: mejor topics por entidad o JSON muy corto

Encaje con tu objetivo hardware universal (Mega/Due/Giga)

• Due/Giga son 3.3 V; Giga confirmado como lógica 3.3 V. docs.arduino.cc

• Para la shield universal ya planteamos buses/periféricos a 3.3 V, y el Mega lee 3.3 V como HIGH, así que UI SPI + ETH/RF SPI encajan perfecto.

Qué haría yo “ya” en el repo (pasos concretos)

1. Crear comm/comm_hal.h con interfaz: begin(), loop(), publish*(), onCommand(...), publishDiscovery().

2. Implementar comm_mqtt.cpp con PubSubClient.

3. Añadir ha_discovery.cpp que genere y publique:

   • device block común

   • una función por dominio (publish_sensor_cfg(...), publish_switch_cfg(...), etc.)

4. Crear un “registry” de entidades (tabla) para que “lo quiero todo” sea data-driven, no código repetido.

5. Añadir “availability” (LWT) y publicar online al conectar.

Si quieres que lo dejemos aún más “ingenieril”: en el siguiente mensaje te puedo definir un catálogo completo de entidades alineado con el Ferduino (relés, dosing, wavemaker, alarmas, temp1-3, niveles, etc.) con:

• unique_id propuesto por entidad,

• topic de estado/comando,

• domain HA,

• y parámetros (min/max/step/device_class/icon).

Perfecto. Vamos a hacerlo como se hace en un proyecto serio y largo, pensado para alguien con base en electrónica, no programador, con control de alcance, documentación, riesgo bajo y aprendizaje progresivo.

Divido la respuesta en dos partes:

1. 📋 Listado completo de entidades Home Assistant (qué se expone, RO / RW)

2. 🧭 Hoja de ruta / plan de acción realista, con fases, objetivos y tiempos orientativos

1️⃣ Catálogo completo de entidades Home Assistant (HA)

Criterio:

• RO = solo lectura (el acuario “informa”)

• RW = lectura/escritura (HA puede mandar órdenes)

• Todo mapeado a MQTT + Discovery

A. Sensores (sensor) – SOLO LECTURA

📌 RO obligatorio – nunca se escriben desde HA

B. Sensores binarios (binary_sensor) – SOLO LECTURA

📌 RO – estados físicos

C. Actuadores (switch) – LECTURA / ESCRITURA (RW)

📌 Desde HA puedes:

• Encender/apagar

• Forzar manualmente (si lo permites)

D. Setpoints (number) – LECTURA / ESCRITURA (RW)

📌 HA escribe → firmware valida → aplica

E. Modos (select) – LECTURA / ESCRITURA (RW)

📌 Ideal para automatizaciones HA

F. Acciones (button) – SOLO ESCRITURA (evento)

📌 No tienen estado, solo evento

G. Availability (global)

• Topic: ferduino/<id>/availability

• online / offline

HA marca todo el dispositivo como disponible o no.

2️⃣ Hoja de ruta REALISTA (sin prisa, con control)

Voy a proponerte un plan de 6 fases, con objetivo claro, entregable, riesgos y duración orientativa.

Importante:
⏱️ No es “tiempo calendario”, es tiempo de trabajo efectivo (ratos libres).

🟢 FASE 0 – Preparación (2–3 semanas)

Objetivos

• Crear estructura limpia

• No tocar hardware todavía

Tareas

• Crear nuevo repositorio GitHub

• Copiar código original sin modificar

• Añadir:

  • README (qué es el proyecto)

  • LICENSE

  • ROADMAP.md

  • docs/

Resultado

✔️ Base sólida
✔️ Historial controlado
✔️ Punto de vuelta seguro

🟢 FASE 1 – Auditoría y documentación (1–2 meses)

Objetivos

• Entender el proyecto sin cambiarlo

• Documentar TODO

Tareas

• Diagramas:

  • bloques funcionales

  • hardware vs software

• Listar:

  • sensores

  • relés

  • pines

  • librerías

• Crear docs/architecture.md

Resultado

✔️ Sabes qué hace cada cosa
✔️ Menos miedo al cambio

🟢 FASE 2 – HAL de placa + compilación limpia (1–2 meses)

Objetivos

• Preparar el terreno para cambios futuros

Tareas

• Crear:

  • hal/board.h

  • hal/gpio.h

  • hal/storage.h

• Reemplazar accesos directos por HAL

• Que compile igual en Mega

Resultado

✔️ Código más limpio
✔️ Base multi-placa

🟢 FASE 3 – Comunicaciones MQTT + HA (2–3 meses)

Objetivos

• Integración completa con Home Assistant

• Sin tocar UI ni hardware

Tareas

• Implementar CommHAL

• Añadir MQTT backend

• Publicar:

  • availability

  • sensores básicos

• Luego discovery completo

Resultado

✔️ Ves TODO en Home Assistant
✔️ Control remoto funcional

🟢 FASE 4 – Pantalla SPI + HAL UI (2–3 meses)

Objetivos

• Cambiar pantalla sin romper UX

Tareas

• Crear DisplayHAL

• Backend UTFT (actual)

• Backend SPI ILI9341

• Migrar pantallas críticas

Resultado

✔️ Menos pines
✔️ Hardware universal

🟢 FASE 5 – Hardware nuevo (shield universal) (variable)

Objetivos

• Diseño eléctrico final

• Compatible Mega / Due / Giga

Tareas

• Esquemático documentado

• PCB 2 capas

• Prototipo

Resultado

✔️ Plataforma reutilizable
✔️ Proyecto “propio”

⏳ Tiempo total realista

👉 Y está bien así.
Este proyecto vale la pena hacerlo lento y bien.

3️⃣ Recomendaciones clave (muy importantes)

• ❌ No intentes hacerlo todo a la vez

• ✅ Documenta ANTES de modificar

• ✅ Commits pequeños y explicados

• ✅ Una fase = un objetivo

• ✅ Si algo compila y funciona → no tocar hasta la siguiente fase

4️⃣ Mi compromiso contigo

Puedo ayudarte:

• a definir cada archivo HAL

• a revisar esquemáticos

• a escribir README / docs

• a definir discovery MQTT exacto

• a revisar decisiones antes de que las tomes

Si quieres, el siguiente paso lógico es:
👉 Definir estructura del repositorio GitHub (carpetas, nombres, convenciones)
y te dejo un esqueleto inicial listo para crear el repo y empezar FASE 0 sin miedo.

Dime y arrancamos por ahí.

Entendido. Y esto no te bloquea: se puede avanzar muchísimo sin tener el hardware, siempre que lo planteemos como un proyecto con simulación parcial + stubs + pruebas por CI, y dejemos el “contacto con el mundo real” para cuando tengas al menos un Mega (o incluso solo un “target de compilación”).

Aquí tienes un plan práctico para arrancar FASE 0 + FASE 1 y parte de FASE 2 sin hardware.

1) Cómo trabajar sin hardware (sin perder el control)

A) Separar “compila” de “funciona”

Sin hardware, tu objetivo al inicio es:

• ✅ que el proyecto compile

• ✅ que las dependencias estén identificadas

• ✅ que exista una “capa mock” para sensores/actuadores

• ✅ que puedas ejecutar al menos “lógica” (setpoints, alarmas, scheduler) en un entorno controlado

La validación física (sensores reales, relés, pantalla) llegará después.

B) Compilación continua (CI) como sustituto de “probar en placa”

Montamos GitHub Actions para:

• compilar para Mega 2560

• (y más adelante) compilar para Due y Giga

Esto te da:

• control de cambios

• garantía de que “no rompiste el build”

• historial limpio para un proyecto largo

C) Stubs / Mocks de hardware (clave para ti)

Creamos un “modo sin hardware”:

• si no hay pantalla → se desactiva UI o se redirige a Serial

• si no hay ethernet → se usa un backend “dummy”

• si no hay sensores → se inyectan valores simulados

Eso te permite desarrollar CommHAL y DisplayHAL sin tener el dispositivo.

2) Qué hardware mínimo te recomiendo (cuando llegue el momento)

No necesitas Ferduino completo para probar.

Mínimo para desbloquear:

1. Arduino Mega 2560 (clon vale)

2. (opcional) Ethernet W5500/W5100 módulo barato

3. (opcional) DS18B20 + resistencia 4.7k

4. (opcional) TFT SPI ILI9341 2.8"

Con solo Mega + Serial ya puedes validar gran parte del firmware.

3) FASE 0 – Crear repo y estructura (lo dejo ya definido)

Estructura recomendada del repositorio

lua
ferduino-next/
  README.md
  LICENSE
  ROADMAP.md
  CHANGELOG.md
  docs/
    00_scope.md
    01_architecture.md
    02_pinmap_original.md
    03_hardware_notes.md
    04_mqtt_ha_entities.md
    05_build_and_ci.md
  firmware/
    original/           <-- snapshot del ZIP, sin tocar
    port/               <-- aquí trabajamos: HAL + MQTT + UI nueva
  tools/
    scripts/            <-- utilidades (generar docs, etc.)
  .github/workflows/
    build.yml           <-- CI compila targets

Convención de ramas

• main: estable

• dev: trabajo diario

• feature/<tema>: cambios concretos (mqtt, ui, hal, etc.)

Convención de issues (para que no se te vaya de las manos)

• type:doc, type:code, type:hardware

• phase:0..5

• priority:p0..p3

4) FASE 1 – Documentación inicial (sin hardware)

Entregables (docs/)

1. 00_scope.md

   • qué entra y qué NO entra (evita scope creep)

2. 02_pinmap_original.md

   • tabla de pines del Mega (del PDF) + descripción por función

3. 01_architecture.md

   • bloques: sensores, relés, RTC, RF, ETH, UI

4. 04_mqtt_ha_entities.md

   • el catálogo “todo” (RO/RW) y topics definitivos

Esto te da un “contrato” técnico.

5) Cómo arrancar FASE 2 sin hardware: HAL “compilable”

Estrategia

• Creamos HAL sin cambiar comportamiento

• Si falta algo de hardware, el HAL tiene fallback:

  • #ifdef FERDUINO_NO_HW

  • o backends “null”

Prioridad HAL para portabilidad

1. hal_watchdog (por el avr/wdt.h)

2. hal_pgmspace (por <avr/pgmspace.h>)

3. hal_storage (para no depender de EEPROM AVR)

4. board_pinmap (para no depender de números mágicos)

Con eso ya podemos compilar “limpio” y empezar CommHAL.

6) CI (GitHub Actions) para compilar sin hardware

Lo mínimo:

• build para arduino:avr:mega

• si falla, el PR no pasa

Más adelante:

• añadir Due y Giga (cuando el HAL esté maduro)

7) Primeros pasos exactos (hoy mismo) para que avances sin bloqueo

1. Crear el repo ferduino-next en GitHub (vacío).

2. Subir el ZIP como firmware/original/ sin tocar.

3. Añadir los archivos base:

   • README, ROADMAP, docs/00_scope.md

4. Añadir CI para compilar Mega.

5. Crear el primer issue: “FASE 1: Documentar pinmap y dependencias”.

Lo único que necesito de ti (para arrancar sin fricción)

Como no puedo crear el repo por ti desde aquí, haz esto:

1. Crea el repositorio en GitHub con el nombre que quieras (ej. ferduino-next).

2. Envíame el nombre/URL del repo (o solo el nombre, si prefieres).

Y en cuanto lo tengas, te preparo:

• contenido exacto de README.md, ROADMAP.md, docs/00_scope.md

• la lista de issues iniciales (FASE 0/1)

• y el workflow de GitHub Actions para compilar Mega

Sin hardware, esto es el camino seguro para que el proyecto empiece “bien” y no muera por caos.

Perfecto. Con ese repo ya podemos arrancar FASE 0 de forma ordenada y sin hardware. Abajo te dejo:

1. Estructura de carpetas que debes crear

2. Contenido inicial listo para copiar/pegar de: README.md, ROADMAP.md, CHANGELOG.md, docs/00_scope.md

3. Un GitHub Actions (.github/workflows/build.yml) que compila (sin placa conectada) usando arduino-cli

4. Lista de issues iniciales para que el proyecto tenga trazabilidad desde el día 1

Nota importante: el build del firmware original puede fallar por dependencias/librerías. Eso es normal. Por eso el plan separa firmware/original (snapshot) de firmware/port (donde hacemos que compile limpio). El CI al principio lo orientamos al “port”.

1) Estructura recomendada del repo

Crea estas carpetas/archivos:

css
ferduino-next/
  README.md
  ROADMAP.md
  CHANGELOG.md
  docs/
    00_scope.md
    01_architecture.md
    02_pinmap_original.md
    03_hardware_notes.md
    04_mqtt_ha_entities.md
    05_build_and_ci.md
  firmware/
    original/
      (aquí metes el ZIP tal cual, sin tocar)
    port/
      README.md
      src/
        main.cpp
      hal/
        hal.h
        board/
          board_mega2560.h
  .github/
    workflows/
      build.yml

2) Contenido inicial de archivos

README.md

md
# ferduino-next

Evolución del proyecto Ferduino Aquarium Controller orientada a:
- Hardware tipo shield para Arduino Mega form factor (Mega 2560 / Due / Giga R1).
- Portabilidad por capas (HAL/BSP).
- Comunicación local moderna: MQTT + Home Assistant (Discovery).
- Sustitución de TFT paralela por TFT SPI (2.8" 320x240) manteniendo UX.

## Estructura
- `firmware/original/`: snapshot del proyecto original (sin modificar).
- `firmware/port/`: implementación evolucionada (HAL, MQTT/HA, UI SPI, etc.).
- `docs/`: documentación viva del alcance, arquitectura, pinmap y plan.

## Estado
Proyecto en fase de arranque: documentación + base compilable sin hardware.

## Principios
1. Cambios pequeños y reversibles.
2. Documentación antes de refactor.
3. CI compila en cada PR.

ROADMAP.md

md
# Hoja de ruta (alto nivel)

## FASE 0 — Setup (semana 1–2)
- Estructura repo + CI de compilación
- Snapshot del código original
- Convenciones: ramas, issues, PRs

Entregable: repo consistente y CI verde (target "port").

## FASE 1 — Auditoría y documentación (1–2 meses)
- Pinmap original (Mega 2560) documentado
- Bloques funcionales (sensores, relés, dosificación, RTC, RF, ETH, UI)
- Inventario de librerías y dependencias

Entregable: `docs/01_architecture.md`, `docs/02_pinmap_original.md`, `docs/03_hardware_notes.md`

## FASE 2 — HAL/BSP mínimo (1–2 meses)
- HAL para: watchdog, pgmspace, storage, gpio
- BSP por placa (Mega 2560 primero)
- Compilación limpia en `firmware/port`

Entregable: build estable sin hardware.

## FASE 3 — Comunicaciones MQTT + Home Assistant (2–3 meses)
- CommHAL + backend MQTT
- Availability (LWT) + publicación de estados
- Discovery completo de entidades

Entregable: integración funcional con Home Assistant.

## FASE 4 — UI SPI (2–3 meses)
- DisplayHAL + TouchHAL
- Backend UTFT/URTouch (compat)
- Backend ILI9341 SPI + touch (XPT2046 o equivalente)

Entregable: UI operativa con pantalla SPI.

## FASE 5 — Hardware (variable)
- Esquemático shield universal 3.3V-first
- PCB 2 capas + prototipo
- Validación eléctrica + EMC básica

CHANGELOG.md

md
# Changelog

## Unreleased
- Repo scaffold + documentación base
- CI de compilación inicial (arduino-cli)

docs/00_scope.md

md
# Alcance (Scope) — ferduino-next

## Objetivo principal
Evolucionar Ferduino hacia una plataforma:
- portable (Mega/Due/Giga),
- documentada,
- con comunicaciones locales modernas (MQTT + Home Assistant Discovery),
- y hardware tipo shield de fácil fabricación.

## In-scope (incluido)
- HAL/BSP para multi-placa
- MQTT + HA discovery (catálogo completo de entidades)
- Refactor UI para soporte TFT SPI 2.8" 320x240
- Diseño de shield universal 3.3V-first (con compatibilidad 5V del Mega)
- Estrategia de almacenamiento NVM (preferible FRAM I2C)

## Out-of-scope (por ahora)
- Integración cloud propietaria Ferduino.com como requisito (puede quedar como backend opcional)
- Pantallas > 3.5" como requisito
- Reescritura total del UI/UX (se prioriza compatibilidad gradual)
- Certificaciones (CE/UL) en esta fase

## Reglas de decisión
- Si algo impacta a hardware: documentar y revisar antes de cambiar.
- Si algo impacta a compatibilidad multi-placa: debe pasar por HAL/BSP.

firmware/port/README.md

md
# firmware/port

Implementación evolucionada del firmware con:
- HAL/BSP,
- CommHAL (MQTT + HA),
- DisplayHAL (SPI),
- build reproducible sin hardware.

Este directorio debe compilar en CI.

3) CI: GitHub Actions para compilar sin hardware

Crea .github/workflows/build.yml con esto:

yaml
name: Build (arduino-cli)

on:
  push:
    branches: [ "main", "dev" ]
  pull_request:

jobs:
  build-mega2560:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Install arduino-cli
        uses: arduino/setup-arduino-cli@v1

      - name: Install AVR core
        run: |
          arduino-cli core update-index
          arduino-cli core install arduino:avr

      - name: Compile firmware/port for Mega 2560
        run: |
          arduino-cli compile \
            --fqbn arduino:avr:mega \
            --warnings all \
            firmware/port

Archivo mínimo para que el CI se ponga “verde” ya

Crea firmware/port/src/main.cpp:

cpp
#include <Arduino.h>

void setup() {
  Serial.begin(115200);
  Serial.println("ferduino-next: port skeleton");
}

void loop() {
  delay(1000);
}

Con esto, aunque todavía no hay HAL ni nada, ya tienes CI verde y un “target de compilación” estable.

4) Issues iniciales (te los recomiendo crear tal cual)

Crea estos issues en GitHub (copiar títulos):

1. FASE 0: Subir snapshot del proyecto original a firmware/original

2. FASE 1: Inventario de librerías y dependencias (original)

3. FASE 1: Documentar pinmap original (Mega 2560) en docs/02_pinmap_original.md

4. FASE 1: Diagrama de bloques y flujo lógico en docs/01_architecture.md

5. FASE 2: Definir estructura HAL/BSP (archivos y API mínima)

6. FASE 3: Definir catálogo final de entidades HA + topics en docs/04_mqtt_ha_entities.md

5) Próximo paso (en orden) para no atascarte

1. Crea carpetas/archivos como arriba.

2. Haz commit “Repo scaffold + CI build skeleton”.

3. Sube el ZIP a firmware/original/ sin tocar y commit “Add original snapshot”.

4. Empieza docs/02_pinmap_original.md (yo te ayudo a rellenarlo a partir de los PDFs cuando quieras).

Si quieres, pega aquí el árbol exacto que te queda en el repo (o una captura del explorer), y te digo si está “listo para fase 1” o si falta algo mínimo.

Perfecto: lo hacemos paso a paso, sin asumir nada y sin meterte 30 archivos de golpe. Vas a conseguir un primer resultado útil en 10–15 minutos: repo con un commit, y ya tendrás “punto de guardado” para no perderte.

Objetivo de este primer paso

Dejar el repo con:

• un README.md

• una carpeta firmware/port con un sketch mínimo que compila

• (opcional hoy) el CI lo dejamos para el siguiente paso

Paso 0 — Comprueba que tienes Git instalado

En tu PC, abre Terminal (Mac/Linux) o PowerShell (Windows) y ejecuta:

bash
git --version

Si te responde algo tipo git version 2.x, perfecto. Si no, instala Git primero.

Paso 1 — Clona tu repo en tu ordenador

Elige una carpeta donde trabajar (por ejemplo Documentos), y ejecuta:

bash
cd ~/Documents
git clone https://github.com/campoyyano/ferduino-next.git
cd ferduino-next

Comprueba que estás dentro:

bash
pwd
ls

Paso 2 — Crea SOLO los archivos mínimos (sin complicarte)

2.1 Crea README.md

Crea un archivo llamado README.md con este contenido:

md
# ferduino-next

Proyecto para evolucionar el controlador Ferduino hacia:
- comunicación local MQTT + Home Assistant,
- portabilidad por HAL/BSP (Mega / Due / Giga),
- y futura shield de fácil fabricación.

2.2 Crea el “sketch” mínimo para compilar

Crea estas carpetas:

bash
mkdir -p firmware/port/src

Crea firmware/port/src/main.cpp con este contenido:

cpp
#include <Arduino.h>

void setup() {
  Serial.begin(115200);
  Serial.println("ferduino-next: port skeleton");
}

void loop() {
  delay(1000);
}

Paso 3 — Guarda y haz tu primer commit

Mira qué va a subir Git:

bash
git status

Añade los archivos:

bash
git add README.md firmware/port/src/main.cpp

Haz el commit:

bash
git commit -m "Add initial port skeleton"

Paso 4 — Sube el commit a GitHub

bash
git push

Si te pide login, GitHub normalmente usa:

• token (si usas HTTPS) o

• login en navegador

Si te sale un error típico, usa esto

Error: “nothing to commit”

Significa que no guardaste bien los archivos o estás en otra carpeta. Ejecuta:

bash
git status
ls -R

y dime qué sale.

Error: “failed to push…”

Suele ser autenticación. Dime el mensaje exacto y te digo qué tocar.

Qué tendrás al final de este paso

✅ Repo con un README
✅ Un firmware mínimo en firmware/port
✅ Un primer commit y push exitoso
✅ Ya no estás “bloqueado por Git”

Cuando completes esto, dime solo qué te devolvió el comando git push (o pega el error si hubo).
Luego pasamos al siguiente paso: añadir la carpeta docs/ y, si quieres, el CI de compilación.

Perfecto, vamos despacio 🙂
Ese mensaje simplemente significa:

Git NO está instalado en tu ordenador.

Es el paso 0 real, así que no has hecho nada mal.

Te guío paso a paso como si fuera la primera vez (porque lo es).

🧰 Paso 1 — Instalar Git en Windows

1️⃣ Descarga Git

Ve a esta página:

👉 https://git-scm.com/download/win

Se descargará automáticamente un archivo tipo:

arduino
Git-2.xx.x-64-bit.exe

2️⃣ Instala Git (muy fácil)

Abre el instalador y dale a Next todo el rato, excepto:

Cuando aparezca esta pantalla:

"Adjusting your PATH environment"

Selecciona:

pgsql
Git from the command line and also from 3rd-party software

Luego sigue con Next hasta terminar.

3️⃣ Cierra PowerShell y vuelve a abrirlo

Esto es importante porque Windows tiene que refrescar el PATH.

4️⃣ Comprueba que ya funciona

En la nueva PowerShell escribe:

powershell
git --version

Debería salir algo como:

nginx
git version 2.44.0.windows.1

Cuando veas ese mensaje

Respóndeme con:

"OK, ya funciona"

Y seguimos con el siguiente paso:

• clonar tu repo

• crear los primeros archivos

• primer commit

Vamos muy poco a poco 👍

Déjalo exactamente como está seleccionado:

✅ Marca:

Use bundled OpenSSH

Y pulsa Next.

Por qué (explicación simple)

• Es la opción más fácil

• Viene todo incluido dentro de Git

• No necesitas configurar nada más

• Es la recomendada para el 99% de los casos

La otra opción (“external OpenSSH”) es para gente que ya tiene SSH configurado manualmente, y ahora mismo no lo necesitas.

Sigue pulsando Next en todo lo demás sin cambiar nada.

Cuando termines la instalación:

1. Cierra PowerShell

2. Ábrelo otra vez

3. Escribe:

powershell
git --version

Y dime qué te aparece 🙂

Déjalo tal cual está seleccionado:

✅ Use the native Windows Secure Channel library

y pulsa Next.

Por qué (fácil y corto)

• Usa los certificados de seguridad de Windows

• Evita problemas raros al conectar con GitHub

• Es la opción más compatible para usuarios normales

La otra opción (OpenSSL) es más para entornos técnicos o servidores.

Sigue dándole a Next en todo lo demás sin cambiar nada.

Cuando termine la instalación:

1. Cierra PowerShell

2. Ábrelo otra vez

3. Escribe:

powershell
git --version

Y dime qué te sale 👍

Aquí no cambies nada, deja la opción que ya viene marcada:

✅ Checkout Windows-style, commit Unix-style line endings

y pulsa Next.

Qué significa (explicado fácil)

• Windows usa saltos de línea tipo CRLF

• Linux/Mac usan LF

• Git convierte automáticamente para que no haya problemas

Para proyectos de programación (como este), esta es la opción correcta y recomendada.

Sigue pulsando Next → Next → Next hasta terminar la instalación.

Cuando acabe:

1️⃣ Cierra PowerShell
2️⃣ Ábrelo otra vez
3️⃣ Escribe:

powershell
git --version

Y dime qué te aparece.

Perfecto, esto es normal y tiene solución rápida 👍
Lo que pasa es que Windows todavía no ha cargado Git en el PATH.

Vamos a arreglarlo en 2 minutos.

🔧 Solución rápida (prueba esto primero)

1️⃣ Cierra TODAS las ventanas de PowerShell

Ciérralas completamente.

2️⃣ Abre una nueva PowerShell

MUY importante: abrir una nueva, no usar la anterior.

3️⃣ Prueba otra vez:

powershell
git --version

Si SIGUE sin funcionar

Entonces Git se instaló, pero Windows no lo añadió al PATH.

Haz esto:

4️⃣ Busca “Git Bash” en el menú inicio

Pulsa el botón de Windows y escribe:

nginx
Git Bash

Ábrelo.

Se abrirá una ventana negra tipo terminal.

Dentro escribe:

bash
git --version

Dime qué pasa:

• Si en Git Bash funciona → perfecto, Git está instalado

• Si tampoco funciona → algo falló en la instalación

Si en Git Bash sí funciona

Entonces solo falta añadir Git al PATH de Windows (lo arreglo contigo en 30 segundos).

Pero primero dime:

👉 ¿Te funciona el comando dentro de Git Bash?

¡Perfecto! 🎉
Eso significa:

✅ Git está bien instalado
✅ Funciona correctamente
❗ Solo falta que PowerShell lo “vea”

Esto pasa mucho en Windows y es fácil de arreglar.

Solución definitiva (1 minuto)

Vamos a decirle a Windows dónde está Git.

1️⃣ Cierra TODO

Cierra:

• PowerShell

• Git Bash

• Cualquier terminal

2️⃣ Reinicia el ordenador

Sí, en serio 😄
Es lo más rápido y normalmente arregla el PATH automáticamente.

3️⃣ Cuando vuelva a arrancar

Abre PowerShell y prueba:

powershell
git --version

Si ahora funciona

Seguimos con el siguiente paso (clonar el repo).

Si aún NO funciona

No pasa nada, lo arreglamos manualmente en 30 segundos.

Pero primero probamos el reinicio porque:

• 8 de cada 10 veces se arregla solo.

Cuando reinicies, vuelve y dime:

• "ya funciona en PowerShell"

• o pega el error si sigue igual.

Genial. Entonces ya podemos empezar con Git paso a paso.

Paso 1 — Clonar tu repo (en una carpeta de trabajo)

1. Abre PowerShell.

2. Ve a tu carpeta de trabajo (te propongo Documentos):

powershell
cd $HOME\Documents

3. Clona el repo:

powershell
git clone https://github.com/campoyyano/ferduino-next.git

4. Entra en la carpeta:

powershell
cd ferduino-next

5. Comprueba que estás dentro:

powershell
dir

Paso 2 — Configurar tu nombre y email (solo la primera vez)

Ejecuta (pon tu email real de GitHub):

powershell
git config --global user.name "Tu Nombre"
git config --global user.email "tuemail@ejemplo.com"

Paso 3 — Crear el primer README (muy simple)

Crea/edita el archivo README.md con este contenido:

md
# ferduino-next

Proyecto para evolucionar el controlador Ferduino hacia:
- MQTT + Home Assistant
- HAL/BSP (Mega / Due / Giga)
- futura shield de fácil fabricación

Si no tienes editor, la forma más fácil es:

• abrir el explorador de archivos en Documents\ferduino-next

• crear/editar README.md con el Bloc de Notas

Paso 4 — Primer commit y push

En PowerShell, dentro de ferduino-next, ejecuta:

powershell
git status
git add README.md
git commit -m "Add README"
git push

Cuando termines, dime qué te sale en git push

• si te pide login, me dices qué ventana/mensaje te aparece y te guío

• si termina bien, pasamos al siguiente paso: crear firmware/port con el sketch mínimo y dejar el repo preparado para CI

Perfecto 👍
Ese mensaje:

"You appear to have cloned an empty repository"

NO es un error.
Significa simplemente:

Sí — 100% recomendable usar Visual Studio Code en tu caso.
Y sí: tiene integración con Git muy buena, pensada precisamente para gente que no quiere pelearse con comandos todo el rato.

De hecho, para este proyecto te va a facilitar muchísimo la vida.

🧠 Por qué VS Code es la mejor opción para este proyecto

Tú tienes este perfil (ideal para VS Code):

• Electrónica ✔️

• Poco código ✔️

• Proyecto grande ✔️

• Aprendizaje progresivo ✔️

VS Code te da:

• Editor cómodo

• Git visual (sin comandos)

• Terminal integrada

• Extensiones Arduino

• Todo gratis

🟢 Ventajas clave para ti

1️⃣ Git integrado (muy fácil)

Dentro de VS Code puedes:

• Ver archivos modificados

• Hacer commit con un botón

• Hacer push con un botón

• Ver historial

Sin usar consola.

2️⃣ Editor muy bueno para C/C++

Te ayuda con:

• Autocompletado

• Colores

• Navegar por el código

• Buscar funciones

3️⃣ Perfecto para Arduino

Hay extensión oficial:

• Compilar

• Subir código

• Detectar placas

4️⃣ Perfecto para proyectos largos

Este proyecto te va a durar meses/años.

VS Code:

• Organiza carpetas

• Permite documentación

• Mantiene todo ordenado

🛠️ Paso siguiente recomendado

Vamos a instalar VS Code ahora mismo.

Descarga aquí:

https://code.visualstudio.com/

Instala con opciones por defecto.

Después de instalarlo

Abre VS Code y haz esto:

1️⃣ Open Folder

• File → Open Folder

• Abre esta carpeta:

lua
ferduino-next

2️⃣ Verás Git integrado automáticamente

En la barra izquierda aparecerá un icono:

css
🔀 Source Control

Ahí podrás:

• Ver cambios

• Hacer commit

• Hacer push

Pregunta rápida para seguir

Antes de continuar:

👉 ¿Ya tenías VS Code instalado o lo vas a instalar ahora?

Responde con una de estas:

• "Ya lo tengo"

• "Lo estoy instalando"

• "No lo tenía"

Perfecto, buena decisión 👍
VS Code te va a simplificar muchísimo todo el proyecto.

Vamos a dejarlo listo en 5 minutos para que puedas trabajar cómodo con Git sin comandos raros.

Paso 1 — Abrir tu proyecto en VS Code

1. Abre Visual Studio Code

2. Pulsa:

mathematica
File → Open Folder

3. Navega hasta donde clonaste el repo antes.
   Probablemente estará en algo como:

vbnet
C:\Users\manuel.campoy\Desktop\Personal\Git\ferduino-next

4. Selecciona la carpeta ferduino-next

Paso 2 — Verificar que Git está conectado

Mira en la barra izquierda.

Verás un icono como este:

css
🔀 Source Control

Haz clic ahí.

Debería mostrar algo tipo:

yaml
No changes

Eso significa:

• Git está funcionando

• VS Code detectó el repositorio automáticamente

Paso 3 — Crear el primer archivo (sin tocar consola)

Dentro de VS Code:

1. Click derecho en el panel izquierdo (donde salen las carpetas)

2. New File

3. Llama al archivo:

README.md

4. Pega esto dentro:

markdown
# ferduino-next

Proyecto para evolucionar el controlador Ferduino:
- MQTT + Home Assistant
- HAL para Mega / Due / Giga
- Nueva electrónica tipo shield

5. Guarda (Ctrl+S)

Paso 4 — Hacer el primer commit con el ratón

Mira otra vez el icono:

css
🔀 Source Control

Ahora debería aparecer:

README.md

Haz esto:

1. Escribe arriba un mensaje:

sql
Primer commit

2. Pulsa el botón:

sql
✔ Commit

3. VS Code te preguntará si quieres añadir los archivos → YES

Paso 5 — Subir a GitHub

Arriba del todo verás un botón que dice:

rust
Sync Changes

Pulsa ahí.

Eso hace:

• Push automáticamente

• Sin comandos

Dime qué ves ahora

Respóndeme con una de estas opciones:

1. "Me ha pedido login"

2. "Ha subido todo"

3. "Me sale un error"

4. "No veo el botón Sync"

Y seguimos.

Perfecto, vas genial 👌
Lo que estás viendo es EXACTAMENTE lo que tiene que salir en un repo vacío.

Te explico qué significa esa pantalla:

• El repositorio está vacío

• Aún no hay commits

• Por eso aparece el botón azul "Publish Branch"

Y eso es lo que vamos a usar ahora.

Paso siguiente (muy fácil)

1️⃣ Primero crea el README (si no lo has creado ya)

En el panel izquierdo:

• Click derecho en el espacio vacío

• New File

• Escribe:

README.md

Pega dentro:

markdown
# ferduino-next

Proyecto para evolucionar el controlador Ferduino:
- MQTT + Home Assistant
- HAL para Mega / Due / Giga
- Nueva electrónica tipo shield

Guarda con Ctrl+S

2️⃣ Ahora vuelve al icono 🔀 Source Control

Arriba donde pone:

mathematica
Message

Escribe:

sql
Primer commit

3️⃣ Pulsa el botón azul:

nginx
Publish Branch

Esto hará todo automáticamente:

• Primer commit

• Push a GitHub

• Conectar el repo

4️⃣ Posible mensaje

Puede salir una ventana para iniciar sesión en GitHub.

Si pasa:

• Dale a Login

• Se abrirá el navegador

• Acepta

Cuando lo pulses

Dime qué ha pasado:

• "Me pidió login"

• "Ya subió el archivo"

• "Me dio error"

Vamos muy bien 👍
Este es el paso más difícil de todo el proceso.

¡Sí, así mismo! 👍
Ya tienes el README.md detectado como cambio.

Ahora haz esto (en orden):

1. En el cuadro de arriba donde dice Message, escribe:

sql
Primer commit

2. Pulsa el botón azul Commit (✔).

3. VS Code te preguntará si quieres Stage All (añadir el archivo). Dale a Yes.

4. Después del commit, arriba (o abajo a la izquierda) verás la opción Publish Branch.
   Pulsa Publish Branch para subirlo a GitHub.

Si te pide iniciar sesión, acepta y sigue el login en el navegador.

Cuando termine, dime:

• “Subido”
  o pega el mensaje que te salga.

Perfecto, vas exactamente bien 👍
Ese mensaje es normal y justo lo que tenía que salir.

Significa:

“No has añadido el archivo todavía.
¿Quieres que lo añada automáticamente y haga el commit?”

Dale a:

👉 Yes

Lo que va a pasar ahora automáticamente:

1. Git añade el README

2. Hace el primer commit

3. Te dejará el repo listo

Después de eso, aparecerá el botón:

nginx
Publish Branch

Cuando lo veas:

👉 Pulsa Publish Branch

Eso sube el proyecto a GitHub por primera vez.

Cuando lo hagas, dime qué pasa:

• "Me pidió login"

• "Ya está subido"

• "Me salió otro mensaje"

Estás literalmente a 1 click de tener el proyecto arrancado 🚀

Perfecto, esto también es normal 👍
Git solo te está diciendo:

“Antes de hacer el primer commit necesito saber quién eres”

Es algo que se configura una sola vez en la vida.

Vamos a hacerlo en 30 segundos.

🔧 Paso rápido (solo copiar y pegar)

Abre la terminal dentro de VS Code:

1️⃣ Pulsa:

nginx
Ctrl + ñ

(o ve arriba a Terminal → New Terminal)

Te aparecerá una consola abajo.

2️⃣ Copia y pega esto (cambiando el nombre y email):

bash
git config --global user.name "Manuel Campoy"
git config --global user.email "tuemail@gmail.com"

⚠️ IMPORTANTE:

• El email debe ser el mismo que usas en GitHub

Ejemplo real:

bash
git config --global user.name "Manuel"
git config --global user.email "manuel@gmail.com"

3️⃣ Pulsa Enter

No saldrá nada.
Eso es buena señal.

4️⃣ Ahora vuelve a intentar el commit

• Escribe otra vez el mensaje:

sql
Primer commit

• Pulsa Commit

• Dale a Yes

Después de eso aparecerá:

nginx
Publish Branch

Y ya lo subimos 🚀

Dime cuando hayas puesto los dos comandos y volvemos a intentar el commit.

No te preocupes, esto es normal y ya sé exactamente qué ha pasado 🙂

Estás usando la terminal integrada de VS Code con PowerShell, y ahí todavía no encuentra Git (aunque Git Bash sí lo tiene).

Vamos a hacerlo por la vía más fácil.

OPCIÓN RÁPIDA (la mejor ahora mismo)

1️⃣ Abre Git Bash (no PowerShell)

Pulsa el botón de Windows y escribe:

nginx
Git Bash

Ábrelo.

Verás una ventana negra distinta, tipo:

nginx
MINGW64 ~
$

2️⃣ Escribe estos dos comandos ahí dentro

bash
git config --global user.name "Manuel"
git config --global user.email "TU_EMAIL_DE_GITHUB"

IMPORTANTE:

• Pon el email que usas en GitHub

Ejemplo:

bash
git config --global user.name "Manuel"
git config --global user.email "manuel@gmail.com"

Pulsa Enter después de cada línea.

No saldrá nada → eso significa que está bien.

3️⃣ Cierra Git Bash

4️⃣ Vuelve a VS Code

Intenta otra vez:

• Escribe el mensaje:

  sql
  Primer commit
  

• Pulsa Commit

• Dale a Yes

Ahora ya NO debería salir el error.

Y después aparecerá:

nginx
Publish Branch

Dime qué pasa ahora:

• ¿Te dejó hacer el commit?

• ¿Te aparece "Publish Branch"?

Buena pregunta 👍 y sí: tienes razón, antes te funcionaba en PowerShell.
Lo que está pasando ahora es algo típico de Windows + VS Code:

VS Code está usando una terminal distinta que no tiene el PATH actualizado.

No te preocupes, no has hecho nada mal.

La solución más simple (sin complicarnos)

Como ya sabes que Git funciona en PowerShell, vamos a configurarlo ahí directamente.

1️⃣ Abre PowerShell normal (fuera de VS Code)

Pulsa botón Windows y abre:

nginx
Windows PowerShell

2️⃣ Escribe estos dos comandos (solo una vez en tu vida):

powershell
git config --global user.name "Manuel"
git config --global user.email "TU_EMAIL_DE_GITHUB"

Ejemplo:

powershell
git config --global user.name "Manuel"
git config --global user.email "manuel@gmail.com"

3️⃣ Cierra PowerShell

4️⃣ Vuelve a VS Code

Ahora intenta otra vez:

1. Escribe:

sql
Primer commit

2. Pulsa:

sql
Commit

3. Dale a:

yaml
Yes

Esto ya debería funcionar sin errores.

Explicación rápida de lo que pasaba

Git necesita saber:

• quién hace los cambios

• con qué email

Eso se guarda en tu PC para siempre.

Y ya está 🙂

Dime ahora:

👉 ¿Te dejó hacer el commit?

Perfecto, entonces estás exactamente donde debes estar 👍
Y sí, lo que hiciste confirma que Git YA está bien configurado.

Te resumo tu estado actual (para que no haya dudas):

✔ Git instalado
✔ Repo clonado
✔ user.name configurado
✔ user.email configurado
✔ VS Code abierto
✔ README creado
❗ Falta SOLO terminar el primer commit correctamente

El problema ahora no es Git… es que VS Code estaba usando una terminal distinta.

Pero vamos a terminar esto de la forma más simple posible usando PowerShell, que ya sabemos que funciona.

Vamos a hacer el primer commit desde PowerShell (más fácil)

Abre PowerShell y ejecuta exactamente esto:

1️⃣ Ve a la carpeta del proyecto

powershell
cd C:\Users\manuel.campoy\Desktop\Personal\Git\ferduino-next

2️⃣ Comprueba que el README está ahí

powershell
dir

Deberías ver:

README.md

3️⃣ Añade el archivo a Git

powershell
git add README.md

4️⃣ Haz el commit

powershell
git commit -m "Primer commit"

5️⃣ Sube a GitHub

powershell
git push -u origin main

Posible cosa que pase ahora

Puede que te diga:

yaml
fatal: The current branch main has no upstream branch

Si pasa eso, usa:

powershell
git push --set-upstream origin main

Qué debería pasar

Git te pedirá login en GitHub:

• Se abrirá el navegador

• Aceptas

• Listo

Cuando termines

Copia aquí lo que te salga después del git push.

Puede ser algo tipo:

• "Everything up-to-date"

• "Branch published"

• o un error

Y seguimos con el siguiente paso (ya empezamos a montar el proyecto de verdad 🚀).

Perfecto, entonces lo dejamos claro:

👉 Vamos a trabajar 100% desde PowerShell
👉 VS Code solo como editor de texto
👉 Git lo manejas tú con comandos (más estable y predecible)

De hecho, para proyectos técnicos largos esto es mejor 👍

Vamos a dejar Git funcionando perfecto en PowerShell

Ya casi lo tienes. Solo falta hacer el primer commit correctamente.

Estás aquí ahora mismo:

vbnet
C:\Users\manuel.campoy\Desktop\Personal\Git\ferduino-next

Y ya configuraste:

arduino
git config --global user.name "Manolo"
git config --global user.email "campoyyano@gmail.com"

Así que vamos a terminar el primer commit.

Paso 1 — Ver si el README existe

En PowerShell escribe:

powershell
dir

¿Ves README.md?

Si NO está:

Lo creamos en 10 segundos:

powershell
notepad README.md

Pega dentro:

powershell
# ferduino-next

Proyecto de evolución del controlador Ferduino.

Guarda y cierra.

Paso 2 — Añadir el archivo a Git

powershell
git add README.md

Paso 3 — Hacer el primer commit

powershell
git commit -m "Primer commit"

Paso 4 — Subirlo a GitHub

powershell
git push -u origin main

Qué puede pasar ahora

Caso A — Te pide login

Se abre el navegador → aceptas → listo.

Caso B — Dice algo como:

lua
error: src refspec main does not match any